微服务读书笔记-读Re：重识微服务架构

原文：https://mp.weixin.qq.com/s/UdLNAnLHo314ESKRUshVQQ

什么是微服务架构？

形像一点来说，微服务架构就像搭积木，每个微服务都是一个零件，并使用这些零件组装出不同的形状。

通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。

学科派一点来讲，微服务架构就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为 HTTP RESTful API）实现通信；

追本溯源，Martin Folwer 对微服务架构的定义是：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建  。（摘自王磊先生的《微服务架构与实践》）

对于我个人，我更喜欢一种延续性的解释，微服务架构 ≈ 模块化开发 + 分布式计算

总结：不管微服务架构的定义怎么样，都是在描述一个核心思想：把大系统拆分成小型系统，把大事化小，以降低系统的复杂性，从而大幅降低系统建设、升级、运维的风险和成本。

微服务”与“微服务架构”的本质区别：微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。

一种错误的描述："”我们可以用微服务来解决这个问题"；我也看到了越来越多的“某某微服务框架”，而实际上，这些框架跟微服务架构不一定有太多联系，它们只是简单的 Web 框架。

使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务。

常见的微服务组件及概念

1.服务注册

服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己

2.服务发现

服务调用方从服务注册中心找到自己需要调用的服务的地址

3.负载均衡

服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。

4.服务网关

服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能

5.配置中心

将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移

6.API 管理以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试

7.集成框架

微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统

8.分布式事务

对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性

9.调用链

记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点

注：跟着小程学微服务-自己动手扩展分布式调用链

10.支撑平台系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。

现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

关于微服务框架选择：

一般情况下，如果希望快速地体会微服务架构带来的好处，使用 Spring Cloud 提供的 服务注册（Eureka）、服务发现（Ribbon）、服务网关（Zuul） 三个组件即可以快速入门。其它组件则需要根据自身的业务选择性使用

附加：dubbo和spring cloud，微服务架构对比及替代方案 见：微服务架构的基础框架选择：Spring Cloud还是Dubbo？

Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。但是在选择框架上，方案完整度恰恰是一个需要重点关注的内容。

Dubbo对于上表中总结为“无”的组件不代表不能实现，而只是Dubbo框架自身不提供，需要另外整合以实现对应的功能，比如：

• 分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。
• 服务跟踪：可以使用京东开源的Hydra
• 批量任务：可以使用当当开源的Elastic-Job
• ……

虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

微服务架构优劣势分析

微服务架构和单体架构的对比

上手难度：API 接口调用 VS 数据库共享或本地程序调用,单体架构胜

待补

什么场景需要使用微服务架构

以上微服务架构和单体应用的对比，会让人产生一种错觉，微服务架构就是软件开发中的银弹。实际上，软件研发是一个系统工程，没有银弹，不能够一招鲜吃遍天。正如当年的 CMMI 和敏捷方法一样，敏捷虽好，但它不一定能适用于所有的场景，它对组织环境、团队氛围、沟通方式、技术能力这些都是有一些要求的，如果用不好，反而会带来一些负面影响。

作者认为有三种场景可以考虑使用微服务：

1.规模大（团队超过 10 人）

2.业务复杂度高（系统超过 5 个子模块）

3.需要长期演进（项目开发和维护周期超过半年）

借一张图来说明：

Tips: 横轴是复杂度，纵轴是生产效率。从生产效率的角度来讲，在两条曲线的交叉点之前，单体架构是占优势的，过了交叉点之后，单体架构的生产效率将大幅度下降。

对一种建议的保留态度：开始的时候先使用单体架构，当业务发展到一定程度的时候，再重构成微服务架构

在实践中，架构改造的难度还是很大的，会有一些问题，例如:

• 客户或业务部门是否给我们这样的时间窗口？

• 这段时间的研发经费是否有出处？

• 项目负责人或技术团队是否有主动的意愿进行架构升级？

• 项目负责人或技术团队是否愿意为架构升级带来的不稳定风险负责？

我们常常听到的一句话是：暂时先这样，等我们没这么忙的时候，再来优化一下。但是，绝大多数情况下，这一天从来没有出现过。

再想想年初，我们的私有云平台经过 2 年多的发展，已经包含了容器服务平台（PaaS）、API 网关、监控平台、定时任务平台、数据库管理、用户权限管理等等十多个基础模块，也包含了一些为上层应用服务提供的日志服务、缓存服务、消息服务等等。并且，部署到了二十多个客户的生产环境里。可悲的是，我们支撑了很多的业务系统的微服务化，但平台本身任然是一个单体系统。

我们也深深地感受到了平台往前发展的阻力：

• 很多时候，客户需要的不是一个大而全的平台，他们希望按他们的意愿采购需要的模块。

• 新人进入团队后，从熟悉到动手产出的时间偏长。

• 其它研发团队有一些比较好的组件能满足平台产品的需求，却不能直接拿来用。

• 两个不同的模块之间产生了不该出现的耦合关系，导致意想不到的 Bug。

所以，春节过后，大家开了一个会，决定将平台微服务化。而带来的代价就是要说服老板给我们两个月时间来重构。

幸运的是，我们很快得到了老板的支持，并且重构工作比较顺利；不幸的是，那二十多个客户的生产环境的升级非常麻烦，每升级一个客户都得花上一周左右的时间，至今也才升级了一小部分。

所以，理想的情况下，我建议在项目初期的时候就从上面提到的三点做好评估，到底采用哪种架构形式是符合项目具体情况的。

当然，如果真的有朋友想将历史悠久的单体架构升级到微服务架构，我建议先从边缘逻辑开始，逐步逐步地将业务逻辑从单体系统里剥离出来。我没有这方面的经验，但可以想象，这将是一个非常长期和痛苦的过程。