王启军：云原生架构下如何拆分微服务？

王启军，云原生技术架构专家，曾任当当架构师，主导电商平台架构设计，包括订单、支付、价格、库存、物流等。曾就职于搜狐，负责手机微博的研发。十余年的技术历练，也曾作为技术负责人带领过近百人的团队。公众号“奔跑中的蜗牛”的作者

1 微服务架构

微服务架构是Cloud Native的重要组成部分，微服务架构给我们带来收益的同时，也会带来副作用，我们应该在什么阶段采用微服务架构？如何拆分微服务架构？拆分粒度多大比较合适？本章内容从问题开始，循序渐进，带领读者逐步深入微服务架构的各个角落。

1.1 微服务架构的起源

2005年，Peter Rodgers博士在云端运算博览会上提出的微Web服务（Micro-Web-Service），将程序设计成细粒度的服务（Granular Services），以作为Microsoft下一阶段的软件架构，其核心思想是让服务由类似Unix管道的存取方式使用，而且复杂的服务背后是使用简单URI来开放界面，任何服务都能被开放（exposed）。这个设计在HP的实验室被实现，具有改变复杂软件系统的强大力量。

2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统，每个服务都以一个独立的进程的方式运行，每个服务与其他服务使用轻量级（通常是HTTP API）通信机制，这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署，同时服务会使用最小规模的集中管理（例如Docker）能力，服务可以用不同的编程语言和数据库。

实际上，微服务的诞生绝非偶然，敏捷开发帮助我们减少浪费，快速反馈，以用户体验为目标；持续交付促使我们更快、更可靠、更频繁地改进软件；基础设施即代码（Infrastructure As Code）帮助我们简化环境的管理，这些都是推动微服务诞生的重要因素。如果没有这些基础，微服务架构在展现魅力的同时，可能由于各种问题导致最终失败。

从SOA架构到服务化架构、再到微服务架构，是一个逐步演进的过程，Amazon被认为是微服务的鼻祖，2015年我曾经接触过一个Amazon的工程师，他并不是特别了解微服务这个名词，直到看完Martin Fowler关于微服务的文章，才发现自己一直在做的就是微服务架构。可以说微服务架构并不是什么技术创新，而是开发过程发展到一个阶段对技术架构的要求，是在实践中不断摸索而来，每个公司所信奉的架构思想有相同之处，但是也不尽相同。这种化繁为简的拆分方式，不只在技术上带来突破，更带来了很多潜在的价值，如关注点分离、沟通效率提升、快速演进、快速交付、快速反馈等。

1.2 为什么采用微服务架构

1.2.1 单体架构VS微服务架构

就像很难用一个绝对的方式去判断架构好坏一样，在大多数场景下，我们也很难从一个外部的视角去判断服务拆分粒度的合理性，需要对上下文非常了解才能做出一个好决策。例如，团队规模多大，代码规模多大，有没有平台化，有没有工具链，是否需要持续交付，团队文化如何等。因此，一个外部的架构师是很难在短时间内将架构规划合理的，这需要一个过程，当真正了解这一切之后，不断权衡，最终确定。在划分之前，有必要参考表2-1，综合各方面的情况，最终做出决策。

表2-1 单体架构VS微服务架构

因素	单体架构	微服务架构	说明
交付速度	较慢	较快	服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率提升，产品的更新速度会更快，用户体验更好。代码规模越大，微服务的优势越明显
故障隔离范围	线程级	进程级	服务独立运行，通过进程的方式隔离，使故障范围得到有效控制、架构变得更简单可靠。根据业务的重要程度划分服务，把核心的业务划分为独立的服务，这样可以从数据库到服务，保持有效的故障隔离，进而保持稳定
整体可用性	较低	更高	微服务架构由于故障范围得到有效隔离，整体可用性更高，降低一点故障对整体的影响
架构持续演进	困难	简单	由于微服务的粒度更小，架构演进的影响面就更小。不存在大规模重构导致的各种问题。微服务架构对架构演进更友好
沟通效率	低	高	业界普遍认为团队规模越大，沟通效率越低，微服务架构按业务构建全功能团队，把权利下放，不会出现决策瓶颈点，降低沟通规模，提升沟通效率
技术栈选择	受限	灵活	如果某个业务需要独立的技术栈，可以通过服务划分，接口集成的方式实现。例如搜索，技术栈、专业细分领域都不相同，通常采用独立的服务实现
可扩展性	受限	灵活	微服务架构可以根据服务对资源的要求以服务为粒度扩展，符合AKF扩展立方体中的Y轴扩展，而单体架构只能整体扩展，只能做到AKF扩展立方体中的X轴扩展
可重用性	低	高