单体架构的优势： 便于开发：只需要借助IDE的开，调试功能即可完成 易于测试：只需要通过单元测试或浏览器即完成测试 易于部署：打包成单一可执于jar/war包，执jar/war包即可部署 单体架构的不足： 复杂性高 代码难以理解，各个模块逻辑复杂。 难以理解导致代码质量低，复杂性进一步增加 代码难以被修改和重构 内存泄露可能导致整个应用的崩塌(微服务可避免) 交付效率低： 构建和部署耗时长，难以定位问题，开发效率低 代码复杂和变更影响难以理解，需要数天完成全量测试 全量部署耗时长，影响范围广，风险大，发布步频次低 不能独立布署，用户体验差 伸缩性(横向扩展)差： 单体只能按整体横向扩展，无法分模块垂直扩展 IO密集型模块和CPU密集模块无法独立升级和扩容 可靠性差： 一个bug有可能引整个应用的崩溃。 难以定位问题 阻碍技术创新： 受技术栈限制，团队成员使用同一框架和语言，很难扩展 升级和变更技术框架变得困难，牵一发动全身。 尝试新语言变得困难(太重)，新需求，重构导致开发成本高。 微服务架构 将单体应用拆分为多个高内聚低耦合的小型服务 每个小服务运动在独立进程，由不同的团队开发和维护， 服务间采用轻量级通信机制，独立自动部署，可以采不同的语言及存储。(不影响进度，各司其职) 优势： 易于开发和维护， 微服务相对单体应用体量更小，易于理解。 启动调试时间短，开发周期短。交付时间短。 独立部署： 不同的服务，并行迭代。(同时进行)不同于单体应用。从上至下，从1到2. 一个微服务的修改不需要协调其它服务。相对于单体应用往往存在，改一处多处报错(整个系统故障)。互不影响 单体应用往往会有改一处BUG引发多处BUG，高耦合，依赖性强。 相比微服务单体调试周期长，部署时间长，连锁反应大。 伸缩性强： 每个服务都可以在横向和纵向上扩展(单体受垂直(纵向)影响) 每个服务都可以按硬件资源的需求进行独立扩容或升级。延伸 与组织结构相匹配： 微服务架构可以更好将架构和组织相匹配(根椐不同的模块化分给不同的团队); 每个团队独立负责哪些服务(模块)，获得更高的效率(生产力) 技术异构性： 使用最适合该服务的技术(跨语言实现)，提供接口即可(服务者,消费者) 降低尝试新技术的成本(尝试新语言更容易)不受架构的影响 根椐不同的服务实现方式采用不同的技术栈 容错性高 微服务之间通信技术： 1.rcp 2.restful 3.异步 服务拆分： 微服务拆分原则：领域模型，组织架构，康威定律，单一职责 微服务拥有独立的数据库,技术栈。 微服务之间确定服务边界， 高内聚，低耦合。 微服务面临的问题 数据一致性(多服务，多事务) 可靠性事件模式 补偿模式-sagas模式 服务通信 通信方案： 同步机制(http协议)：RPC vs REST 跨语言，学习成本低，易上手 异步机制(通常基于TCP)：AMQP(异步消息) 不方便测试 ，调试。 服务注册和发现： 注册中心： Eureka,ZK.Consul 等等三方框架 负载均衡 nginx ,ribbon 服务网关(服务通信) API Gateway(聚合作用，应避免业务代码) 身份认证，路由服务，安全过滤，流量控制，日志统计 高可观察 健康检测，集中监控，聚合输出 日志聚合及检索(脚手架) 分布式追踪(定位问题，优化)，服务故障 可靠性 流量控制，超时控制。保证下游服务正常 舱避隔离，熔断机制(服务出错，调用次数过多)关闭服务调用功能 请求转移， 服务降级，幂等重试 服务降级策略，(网络问题)，服务重试。 接口幂等性。