云原生时代（三）：微服务、API管理与集成

上文我们主要介绍了DevOps与CI/CD，第三部分我们来讲云原生的核心概念-微服务。

---

什么是微服务

微服务（Microservice）概念最早出现于2012年，2015年以后受到越来越多的关注，并且逐渐开始流行开来。其中著名技术大神Martin Fowler功不可没，他于2014年发表的一篇博客《Microservices: a definition of this new architectural term》（微服务：新技术架构的定义）清晰的定义和阐述了微服务概念。

“要开始解释什么是微服务之前，先了解单体（Monolithic）应用是很有用的：作为一整个单元构建的应用程序。企业应用由三个重要部分组成：客户端界面（由HTML、Javascript组成，使用浏览器访问）、数据库、服务端程序。服务端程序处理HTTP请求、执行业务逻辑、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端程序是一个单一结构也即一个整体，系统中的任何修改都将导致服务端重新编译和布署一个新版本。

这样一个单体应用很自然的被构建成为一个系统，虽然可以使用开发语言的基本特性把应用封装成类、函数、命名空间，但是业务中所有请求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运行和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。

的确，单体应用也非常成功，但是越来越多的人感觉到了不妥，特别是应用程序被发布到云的时候，变更周期被捆绑在一起-对应用程序一小部分所做的变更，都需要重新编译和部署整个应用。随着时间的推移，软件开发者很难保持一个好的模块架构，使得单个模块的变更不会影响到其它模块，而且扩展时也只能进行整体扩展，而不能根据需求进行部分扩展。”-- Martin Fowler

下图是传统单体应用的技术及对应的组织架构，Martin Fowler称之为大家已熟知的Siloed Architectures-烟囱式（也称为谷仓）架构。

传统单体应用的架构及对应的职能型组织架构

综上，传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个庞然大物。单体应用的局限性大体包括以下几方面：

• 复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差

• 交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低

• 伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展

• 可靠性差：一个bug有可能引起整个应用的崩溃

• 阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言

解决这一问题的银弹就是微服务。

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API)。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。”-- Martin Fowler

微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

下图左边是传统的单体应用，右边是微服务模式，图中每种颜色代表一种可拆分的微服务应用。

 单体应用和微服务

一个比较形象的例子是装配式建筑。传统建筑（单体应用）的施工周期（开发时间）很长，往往依赖于建筑公司（开发团队）的能力和水平，修建完成后难以搬迁和复用，而装配式建筑（微服务）的梁、板、柱、墙等构件（单个服务）可以事先批量化的在工厂（容器）生产，而在建造过程中，我们可以把构件想象成一块块乐高积木，在施工现场只需把它们拼合在一起，大大提升了施工进度和建筑质量。

装配式建筑：乐高积木

微服务的特征包括：

• 小：粒度小，专注于一件事

• 独：单独的进程。微服务不等于组件，服务是可以直接使用的商品，组件是待加工的原材料

• 轻：轻量级通信机制，通常是HTTP Restful的接口。此处区别于传统的SOA（面向服务的架构）

• 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行

微服务采用独立的数据库服务，数据去中心化

 

微服务运行在独立的进程中，部署去中心化

微服务架构的好处是：

• 易于开发与维护：微服务相对小，易于理解

• 独立部署：一个微服务的修改不需要协调其它服务

• 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容

• 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本

• 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡

微服务的实践有两个重要问题：什么时候选择微服务架构，以及颗粒度如何拆分，与经验和实际情况息息相关。

上图来自Martin Fowler另一篇叫《微服务进阶》的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。

我个人建议是除非在可见的将来，复杂度都不会显著提高的情况下，才选择单体应用，否则其它时候都应提前为微服务架构做好设计和准备。

---

微服务基础设施及案例

下图是一个典型的微服务技术架构图。

微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。

但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。

下面我们举一个例子。传统的电商的技术架构如下图所示，这是一个单体应用。

所带来的常见问题包括：

• 不同客户端产品之间，例如小程序、App、网站端有许多相同业务逻辑的重复代码，每个产品都要各自维护一份代码，修改的时候所有地方要一起修改。

• 单个应用经常需要给其他应用提供接口，渐渐地越来越复杂，包含了很多本来不属于它的逻辑，代码变得臃肿，功能边界模糊。

• 系统代码耦合性高，相互之间逻辑复杂，一旦出现开发离职的情况，继任者需要花很长时间review代码，才有可能搞清楚整体架构和逻辑关系。

• 多个应用使用一个数据库，依赖性严重，很难重构和优化。所有应用都在一个数据库上操作，数据库很容易出现性能瓶颈。同时数据库成为单点，出现意外整个系统都会受到影响。

• 即使只改动一个小功能，也需要整个应用一起发布，发布流程繁琐、上线时间长。并且很容易出现一个小bug影响整个系统，每次发布都是胆战心惊，很容易出现开发、运维和测试之间的矛盾。

下面我们用微服务重构整个系统：

 改造之后，去除了大量冗余代码，系统复用性得到提升；不同的团队专注于不同的微服务，代码和工程质量得到保证；数据库不再存在单点问题，系统健壮性得以提升；前后端分离，业务逻辑更加清晰；降低了系统耦合性，不同的微服务可以分开部署上线，相互之间并不影响。

---

组织挑战、康威定律与蜂群理论

请注意，微服务理念不仅反映了技术架构的变化，也反映了组织内部沟通结构为了应对更加灵活、快速、碎片化的需求和环境而变化的结果。例如液态组织就是组织形态应对当前市场环境快速变化的一种输出形式，但实际应该如何构建？

曾经有一张非常有名的组织架构图，如下图所示。