《从零开始学架构》十： 微服务和微内核架构

1 深入理解微服务架构

1.1 对比SOA

1 服务粒度：整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。

2 服务通信：
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现；
微服务推荐使用统一的协议和格式，例如，RESTful 协议、RPC 协议，无须 ESB 这样的重量级实现，且仅仅做消息传递，对消息格式和内容一无所知。

3 服务交付：
SOA 对服务的交付并没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；
微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。

4 应用场景：
SOA 更加适合于庞大、复杂、异构的企业级系统；
微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付。

SOA 和微服务本质上是两种不同的架构设计理念，只是在“服务”这个点上有交集而已

微服务并没有减少复杂度，而只是将复杂度从 ESB 转移到了基础设施

1.2 微服务的复杂性

1 如果服务划分过细，则服务间关系会很复杂

2 如果服务数量太多，团队的开发效率会急剧下降

3 如果调用链太长，导致性能下降、问题定位困难

4 如果没有自动化支撑，则无法快速交付

5 如果没有服务治理（服务路由、服务故障隔离、服务注册和发现等，需要依赖自动化的服务管理系统），微服务数量多了后管理混乱

1.3 最佳实践-方法

1.3.1 如何把握拆分粒度（服务粒度）

基于团队规模进行拆分：
微服务设计和开发阶段，一个微服务三个人负责开发；
维护阶段，平均 1 个人维护 1 个微服务甚至几个微服务都可以，考虑到人员备份问题，则每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。

1.3.2 按照什么维度进行拆分（拆分方法）

• 1 基于业务逻辑拆分

根据团队规模划分业务模块的粒度

• 2 基于可扩展拆分