微服务架构介绍

微服务架构介绍

1

微服务是个说的挺长时间的概念，也是比较成熟的技术体系。像 Spring Cloud，甚至提供了微服务所需要的全套框架，包括注册中心 (Eureka)、配置中心 (Config)、断路器 (Hytrix)、API 网关 (Zuul) 等组件。微服务体系庞杂，每个组件都能独自成章。

微服务与更早就起来的 SOA 是什么关系? 个人觉得如果从概念上来说，微服务和 SOA 都是一回事，强调把整个系统，按照多个服务的方式去组合及通信，而不是揉合在一起，但它们的内涵有很大的区别。

SOA 诞生在早期企业级的应用，其业务复杂、技术体系多样，SOA 强调的是各个服务之间，尤其是异构系统、遗留系统之间，建立起一套统一的协议和通信 (SOAP)，以及寻址服务 (UDDI)，它的侧重点在集成和兼容；与 SOA 同期的另一种概念 ESB(企业总线)，强调通过一根总线服务，把所有服务串联起来，由 ESB 总线来屏蔽各种不同业务系统自身业务 / 语言 / 协议的特殊性，各服务以一种统一的方式，与总线相连，从而降低接入成本。

这两种概念，我感觉在国内没有太发展起来。一是国内的软件起步相对较晚，系统的整体复杂度——多厂商、多语言 / 技术栈、历史遗留系统的问题，还不算突出。而对于公司内部的产品系，又没有必要使用 SOA、UDDI 来做复杂的集成。随着互联网的兴起和用户量的迅速爆发，企业自身的产品的微服务化的需求，快速发展起来，而与此同时 SOA 这种以 XML 为基础的 SOAP 协议、以寻址为主要作用的 UDDI，不能使用互联网产品的发展——SOAP 的 XML 协议内容太多，造成性能明显下降；HTTP 协议的效率不如 RPC；UDDI 只有寻址，缺少服务治理等功能。

在此种大背景下，以服务切分 + 服务注册 + 服务治理 + 限流降级 +RPC+ 监控等为主要内涵的微服务，就快速发展起来的。国内的阿里巴巴走在前列，以 Dubbo 为代表在国内互联网企业中得到广泛应用；后来 Spring 官方发布 Spring Cloud，揉合了一系列自研或其他企业捐赠的开源项目，发布微服务领域的 Spring Cloud 产品。各自都有各自的优势和劣势，而

2

随着这些年来，微服务的继续下沉 (sidecar 和 service mesh) 到基础设施层，给微服务的治理带来了新的方向。

微服务的关键特性 服务粒度

服务的粒度，切分到多大算合适? 太粗的话，这服务就涵盖过多的业务逻辑，从而难维护、易出错；太细了，就会搞出很多的工程，造成很大的工程维护和通信成本。

主流说法是依据康威定律——团队的交流机制应该和组织机构相匹配。应用到软件领域来看，如果某个应用，需要多个组织之间一起交流和修改，那么它的交流机制就大于组织机构了，出现了不匹配的情况，那么这个应用很可能就太粗而需要拆分。

这里有个不太好懂的地方——既然系统架构和团队组织机构想匹配，那我们是先定系统架构呢，还是先定团队组织机构呢? 这有点类似先有鸡还是先有蛋。我觉得可以这么来理解：无论是团队怎么定、还是架构怎么定，这都是跟着业务的发展而发展的，可以说都是业务的衍生发展而来。所以系统架构设计，首要做的还是业务理解和切分——业务切分决定了服务切分、业务切分也决定了团队组织。 业务切分有两种简单办法：

1. 参照业内同类公司的划分：比如电商，业内比较成熟的：支付、库存、订单、搜索、用户等； 2. 将自身业务的主要信息流画出来，先找出其中的名词或动名词，它就可能是个服务

eg：在我们的线上贷款业务中，典型的 user case 是这样： 1. 用户导入几项金融资料数据 2. 系统根据信息清洗出部分衍生变量 3. 系统跑欺诈规则

4. 系统计算授信，给出额度 5. 用户试算得到月费率和利息

3

6. 系统人工信审 7. 系统放款

8. 到还款日时用户还款或者我们系统主动扣款

将其中的名词整理出来，整理流程大概就是如下图：

这些都是候选服务。根据其复杂度和相关性，做适当的拆解和合并，形成了如下几个子系统及服务。

治理范围

4

从服务的角度来看，对外公开的是契约——即我们系统提供哪些特性，而内部算法 / 数据都应该隐藏起来，而在不同服务间“是共享数据库还是独享数据库”上，实践中的冲突和困惑，体现地比较明显。

我们假想个流程，ServiceA 的李雷需要更新 User 表的某个字段，如果大家数据库表都共享的，李雷只要写个 SQL 就解决了。但一旦把 User 表服务化后，归到 UserCenter 这个服务自治之后，问题就麻烦了：

1. 李雷要去找 UserCenter 团队——假设是韩梅梅接了这个需求，好在是个女生，男女搭配干活

不累——讲清楚他的需求或提供需求文档；

2. 韩梅梅理解了需求，设计接口、提供文档、评审并准备开发； 3. 韩梅梅可能手里有其他事，所以这个需求大概要等几天才能开发；

4. 终于韩梅梅开发完了，她要自测、部署；上游李雷开始联调，如果有问题，需要双方再沟通解

决；

5. 联调完毕上线，韩梅梅的 UserCenter 先上，李雷的业务系统再接着上；

从这可以看到，一旦一个人、一个系统做的事，变成了 2 个人、两个系统来做，那要多出多少麻烦了。所以我完全理解，在公司早期，所以业务系统共享一套数据库表，是多么地务实。我们功夫贷在创业之初也是这么做的，在创业 2 年后，它的弊端开始密集体现，而服务化改造过程中，我们也是付出了相当大的代价。

随着用户量和数据量的上升，这种共享数据库表的最明显的弊端就是慢查询越来越多——因为谁都可以操作任何一张表、而开发过程中或者是对业务理解不够、或者是 SQL 能力不足，很容易写出慢 SQL 来，其结果就是导致 DB 的 CPU 飙升到 100%、或者是 IOPS 被打满，从而全 APP 被拖慢甚至无法提供服务。这种危害是相当巨大的。

5