微服务架构浅析及实践心得

1. SOA 与微服务

　　面向服务（SOA）已经不是一个新名词了，跟 Paxos 有一样古老的年龄，其本质是一种软件架构的设计思想。类似“云计算”的分层和服务提供概念（IaaS==>PaaS==>SaaS），SOA 是把企业应用的业务功能以能力开放的形式提供出来，比如通过构建企业服务总线 ESB 来实现企业应用间的服务集成和编排。

而微服务更多的是对 SOA 的一种实践方式（ESB 也是 SOA 的一种实现方式），主要针对企业应用系统本身的架构设计做解耦和组件服务化，从业务上把原来庞大的系统拆分为多个可以独立设计、独立开发、独立部署的小应用，小应用之间通过特定的交互协议（RPC/HTTP 等）完成服务的暴露和调用。

　　关键词：组件服务化，去中心化，分布式，自动化部署和发布

2. 微服务与传统集群

　　传统集群的常见架构一般是前端做负载均衡（F5、apache、nginx）反向代理一堆 Web 容器中的 war，通常一个 war 就是整个应用（把整个应用放在一个进程中），后端再接统一的缓存和 DB 等等。而微服务的一种可能设计是前端做负载均衡，请求代理到控制层后调用部署在不同机器上的小应用来共同完成一次请求，小应用之间也会有相互的依赖调用，各个小应用本身可以有自己的缓存和 DB，也可以多个小应用共用同一个持久层。

　　网上的一个对比图：左边是传统集群，右边是微服务，可以看到一个微服务的小应用就是一个进程，小应用之间的相互调用是通过进程间的通信实现的而不是传统组件依赖中的代码调用，这样就非常方便做到分布式部署了。

　　在 web 开发和部署中的对比如下图所示：

3. 为什么需要微服务

　　支撑互联网公司快速发展的业务系统面临着不断的迭代，当系统规模达到一定的量级后就会发现重构是一件必须要进行但又非常痛苦甚至不可能完成的事情。系统的可扩展可伸缩性一直是架构师努力追求的目标，“业务拆分”是最自然有效的办法，各个业务模块相互独立，形散而神聚，共同构建出一个功能强大的支撑系统。

　　参考《大型网站技术架构》当中典型的系统演进路线和设计模式，系统的发展最后都会走到分布式的路子上来，从“单工程单实例单库”到“多工程多实例多缓存分表分库”，系统的规模越来越庞大，复杂度也越来越高，考虑重构的时候首先从业务上寻找突破，能够从业务角度做出拆分的话，那么就不要勉强的把系统和代码揉合到一起，只有当系统本身作为一个独立的业务体时还是太庞大时那么才考虑微服务。

4. 微服务实现

　　“开发未动 设计先行”，实现系统的微服务化需要一些先决条件和很多的准备工作，首先是系统架构的总体设计，微服务中小应用的边界一般是原系统中的一个业务模块，下图是中国电信 CRM3.0 的总体系统架构图，微服务层面主要是按照业务模块划分了客账户中心、订单中心、资产中心、资源中心等将近 15 中心化的微服务，各中心自治，独立开发和发布，可以实现服务的快速迭代（从图中也可以看到 ESB 的影子）。

网上找的一张京东 IM 咚咚架构图做对比（微服务化）

　　实施微服务带来系统架构的变化的同时也会带来开发团队组织架构的变化（这是我结合以前工作经历画的一个草图）以前我们分前台组，后台组，规则组，架构组等，实施微服务后，按中心做划分，一个中心由一个小团队负责，团队成员可能有前台也可能有后台。

　　组织架构调整好后就是开发流程，微服务更多强调的是“协议先行”（报文协议先约定好，然后并行开发），以及谁开发谁维护，开发人员参与到应用的整个生命周期。

　　开发中一些好用的平台化工具：

　　　　自动化构建部署：Jenkins+Docker

　　　　统一日志平台：Hlog

　　　　统一配置平台：uniConfig/CMDB

　　　　统一监控管理平台：AI-HPaaS

　　　　在线 API 编辑和管理：ShowDoc（这个挺重要的，目前很多系统开发中接口都没有形成文档，导致后期维护升级很麻烦）

5. 服务治理框架

　　微服务要求线上系统具备水平扩展的能力，那么小应用和小应用之间的调用就不能直接写成固定的 IP 地址了，这时候一般引入第三方的服务治理框架 Spring Cloud /Dubbo（Dubbox）来做到服务发现、服务注册、负载均衡、过载保护（熔断和降级）等等。

Spring Cloud（Eureka）：一般以 Spring Boot 为基础实现快速构建微服务应用，应用也不再是必须打包成 war 部署到 web 容器中，而是打成 jar 包，直接 java -jar XXX.jar 运行。

Spring Cloud 中一些重要的组件有：Eureka、Robbion、Zuul、Hystrix、Config 等等

Dubbo：注册中心（Registry）一般可以用 zookeeper 或者 redis 等实现，通过注册中心来实现服务的自动注册和发现。

6. 潜力与挑战并存

**　　优势：**

　　可扩展性：解决了企业应用持久化层的瓶颈问题（关系数据库单机性能问题以及 NoSQL 还不能完全替代数据库成为持久层解决方案），同时，符合设计模式的单一职责原则，一个微服务应用本身只专注于某一个业务模块，可以根据业务特性单独架构和优化更新，甚至选择不同的技术栈，而且小应用本身代码行数少相对来说产生 Bug 的几率也减少，也更利于小应用本身的测试和维护。

　　可用性：通过服务熔断和降级可以有效保证应用系统的整体可用性，即使某个微服务的某个实例挂掉也不会影响系统的其他功能。同时系统可水平扩展以提高整体吞吐量来适应业务的快速发展或者是并发量的突然增加（如电商的秒杀和运营商的促销活动等）

　　并行开发：因为小应用之间是解耦的，这样就可以尽早约定接口协议然后开发人员并行开发，只要协议不变，那么服务调用方对服务提供方的变化是无感知的，这样降低了业务模块之间的耦合度，有利于快速构建系统的原型。

**　　不足：**

　　系统复杂性增加：1.整个系统的内聚性降低了，经常会出现来了某个需求，要改好几个服务（分别由不同的小团队配合完成），工作中也经常听到同事诉苦“之前一句 SQL 就搞定的接口现在要调 3/4 个服务）。2.由于天生的分布式特性，势必会带来数据一致性的问题，这对系统架构师是个很大的挑战（必须从业务上寻找突破口来实现最终的一致性）。3.系统工程数量急剧增加，四川电信 CRM 系统实施微服务后工程数量由原来的 40 个不到一下子增加到 120+，给源码管理和版本管控带来了很大的挑战。

　　运维难度增大：变更或升级的管理难度增大，服务之间经常是 A 依赖 B，B 依赖 C，然后 C 又依赖其他，对于已经约定好的报文协议很难做修改（对扩展开放，对修改关闭），同时由于服务数量的增加和服务本身的无状态带来了服务的监控与治理变得更加复杂要依赖强大的服务治理框架。

　　管理难度增大：开发和测试时只能通过模拟报文或者直连的方式调用服务提供方的接口，增加了团队沟通成本和协调管理的难度。

7. 总结

　　微服务架构只是金字塔尖的那一朵小红花，需要下面一层层的 Pass 绿叶来陪衬。实施微服务需要基础设施的自动化（包括自动化构建、测试、部署和监控等），同时也要求开发团队组织架构的调整来适应新的开发模式（微服务很适合敏捷开发，可以实现快速构建快速交付，迭代发布）。

　　幸运的是目前 Java 平台已经有很多很多成熟的 PaaS 中间件来解决企业应用在微服务化重构时遇到的挑战。

　　软件架构总在不断演进，微服务之后会是 Service Mesh 么？