微服务概览

一、单体架构的不足

传统的 Web 应用架构如下图所示：

尽管它也是模块化逻辑，但是最终它还是会打包并部署为单体式应用，最终演变为一个单一的巨石架构。这样会存在很多问题：

• 应用比较复杂，没有人能够搞懂；
• 应用扩展比较复杂，可靠性比较低；
• 无法进行敏捷开发和部署。

所以一般这个时候就会考虑按照服务、功能进行拆分，如下就是一个粗略的拆分：

二、什么是微服务

2.1 微服务的起源

大家经常谈论 SOA（面向服务的架构），它和微服务又是什么关系？你可以把微服务想成是 SOA 的一种实践。除此之外，微服务还有一些更细致的定义：

• 小即是美：小的服务代码少，bug 也少，易测试，易维护，也更容易不断迭代完善的精致进而美妙；
• 单一职责：一个服务也只需要做好一件事，专注才能做好；
• 尽可能早的创建原型：尽可能早的提供服务 API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢再做；
• 可移植性比效率更重要：服务间的轻量级交互协议在效率和可移植性二者间，首要依然考虑兼容性和移植性。

2.2 微服务的定义

微服务是围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。

三、微服务的优缺点

3.1 微服务的优势

• 服务拆分后比较小，BUG 少，容易测试和维护，也容易扩展；
• 原子服务：一个服务只做一件事情，并且这个属于这个服务的也不应该拆分到其他服务去；
• 独立进程：一个服务只有一个独立进程，可以很好的和当前的容器化进行结合，无状态的服务可以很容易的享受到 k8s 上的故障转移、自动重启等好处；
• 隔离部署：每个服务之间独立部署，可以避免相互影响，并且和按需进行分配资源，节省成本；
• 去中心化服务治理
  • 数据去中心化：每个服务独享数据库、缓存等设施，也有个别情况多个服务共享数据库，例如面向用户的管理后台和面向管理员的管理后台；
  • 治理去中心化：当流量变大，服务之间很容易出现热点，比如账号服务几乎是所有服务都要依赖的服务，因此需要考虑治理去中心化；
  • 技术去中心化：每个服务可以使用适合自己的技术进行实施，但是注意如果技术栈过于发散对于企业或者团队本身也是不利的。

3.2 微服务的不足

• 服务之间的依赖关系复杂，成千上万个服务相互依赖就像一团乱麻一样，剪不断理还乱。
  • 常见的解决方案：全链路追踪，例如：OpenTracing。
• 微服务本身是 分布式系统，由此会带来固有的复杂性。开发者不得不使用 RPC 来做消息传递，来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
  • 例子：服务调用流量会容易被放大，服务 A -> B -> C，如果 A 有一个循环调用 B，B 也有一个循环调用 C，那么一个请求到达 C 之后就被放大了 100 倍甚至上千倍，这是扛不住的。
  • 常见解决方案：粗粒度的进程间通信（batch 接口，批量请求，避免 n+1 问题），隔离，超时保护，负载保护，熔断、限流、降级、重试，负载均衡。
• 分布式事务问题，因为现在每个微服务之间都会有一个独立的数据库，事务在单体应用中很好处理，但是在跨服务时会变得很麻烦。
  • 本质解决方法：本地事务 + 消息队列，最终进行二阶段提交。
  • 小米信息部技术团队：分布式事务，这一篇就够了 (opens new window)
• 测试会非常复杂，由于依赖多，无法得知是因为功能异常还是依赖的某个服务发版出现问题。
  • 常见解决方案：独立测试环境，后面会有一个解决方案。
• 服务模块间的依赖，应用的升级有可能会波及多个服务模块的修改。
  • 切记，在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务契约（接口）的兼容性。
  • 发送时要保守，接收时要开放。按照伯斯塔尔法则的思想来设计和实现服务时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍冗余数据，保证兼容性。
• 对基础建设的要求很高，基础设施需要自动化，日志采集，监控数据采集，告警，CICD，k8s 等。
  • 常见解决方案：小企业上云，大企业自建。

四、如何构建微服务

4.1 组件服务化

传统实现组件的方式是通过库（library），库是和应用一起运行在进程中，库的局部变化意味着整个应用的重新部署。而微服务的核心是 组件服务化，通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。微服务的构建可分为以下几个部分：

• kit：一个微服务的基础库（框架）。
• service：业务代码 + kit 依赖 + 第三方依赖组成的业务微服务
• rpc + message queue：轻量级通讯

本质上等同于，多个微服务组合（compose）完成了一个完整的用户场景（usecase）。

4.2 按业务组织服务

按业务能力组织服务的意思是 服务提供的能力和业务功能对应，比如：订单服务和数据访问服务，前者反应了真实的订单相关业务，后者是一种技术抽象服务，不能反应真实的业务。所以按微服务架构理念来划分服务时，是不应该存在数据访问服务这样一个服务的。

若要按微服务的方式来构建应用，也需要对应调整团队的组织架构。微服务是比较鼓励闭环团队的，每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能，具体工作模式如下图所示：

简而言之，开发团队要对软件在生产环境的运行负全部责任！

4.3 基础设施自动化

无自动化不微服务，自动化包括测试和部署。单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、监控和部署的复杂度都会相应增大，必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。

• CICD：Gitlab + Gitlab Hooks + k8s
• Testing：测试环境、单元测试、API 自动化测试
• 在线运行时：k8s，以及 Prometheus、ELK、Conrtol Panle