1. 单体应用架构存在的问题

1. 复杂性高
   • 包含模块多
   • 模块边界模糊
   • 依赖关系不清
   • 代码质量残次不齐等等
2. 技术债务
3. 部署频率低
   • 功能变更或缺陷修复都要重新部署整个应用。
   • 全量部署 耗时长。影响范围大、风险高。
4. 可靠性差
   • 一个bug可能会导致整个系统的崩溃
5. 扩展能力受限
   • 只能整体扩展，无法根据业务模块进行伸缩。
6. 阻碍技术创新
   • 一般使用统一的技术平台或方案解决所有问题。例如一个使用struts2的100万行代码的单体应用，如果想换成springMVC，成本是非常高的。

2. 微服务简介

并没有严格的定义，将一个单一应用程序开发为一组小型服务的方法。构建的是分布式系统。

2.1. 特性

1. 每个服务运行在自己的进程中
2. 一系列服务共同构建起整个项目
3. 服务针对独立业务，只关注某个特定功能
4. 服务间通信采用轻量级通信机制（如http资源api）
5. 可以使用不同的语言，不同的存储
6. 全自动部署机制

3. 有点

1. 易于开发维护
2. 单个服务启动快
3. 局部修改易部署
4. 技术栈不受限
5. 按需伸缩

4. 挑战

• 运维要求高
  • 需要保证几十个甚至上百个服务的正常运行与写作
• 分布式固有的复杂性
• 接口调整成本搞
• 重复劳动
  • 重复功能不足以分解为一个微服务，可以封装为公共组件，但是多语言就不一定行得通

5. 设计原则

• 单一职责原则
• 服务自治原则
  • 治具备独立的业务能力、依赖与运行环境。
• 轻量级通信机制
  • 体量轻
  • 跨语言
  • 跨平台
  • 常用的有REST AMQP STOMP MQTT
• 微服务力度

康威定律：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片（来源于互联网，侵删），再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。

用通俗的说法就是：组织形式等同系统设计。

6. 如何实现微服务架构

6.1. 技术选型

从开发和运行平台两个维度考虑：

• 开发框架
  • spring cloud
  • dubbo
  • dropwizard
  • armada
• 运行平台
  • 并不绑定运行平台
  • PCServer
  • 阿里云
  • aws
  • Docker

    7. 架构图