微服务学习笔记 1——Prelude

三个月前做的笔记，后来学到了服务注册和发现，负载均衡模式就停下了。最近可能要捡起来也说不定。

对微服务的学习是至关重要的，这个论断是绝对正确的，单体应用已经难以承受当前的互联网时代的复杂度，且性能等因素也受摩尔定律的约束无法更多提升。无论是对当前还是遥远的将来（？），微服务对工程实践都将是有重大影响的。即使以后分布式技术继续发展，人们发现了什么比微服务更好的分布式架构，对微服务的理解也将会有巨大帮助。

本来打算去看《微服务架构设计模式》这本书来进行学习，但进行一些学习后发现这本书实在不适合初学者——概念太多，实践/示例太少，没有相应实践经验的人（That’s me！）难以消化。因此此书我认为应当在有一定经验的基础上再进行阅读，即使该书作者似乎并非以此为出发点。

当前在看的书是《Spring Microservices in Action》第二版，粗略地翻了翻，感觉还不错，就以此来作为敲门砖了。这书正巧第二版最近刚出，还没有中文翻译，同时也能多学学英文。

Prelude

一个有趣的事实是，这两本书都强调在微服务架构中的模式，即对微服务架构中面临的各种问题/需求的形式化的描述和解决方案，在这之前我还未能理解为何在此处要特意使用模式来描述，而最近才意识到，将这些问题抽象为模式是在解决方案和特定技术/中间件中增加了一道抽象层，从而避免解决方案耦合于特定的技术/中间件，让架构真正成为架构，而非特定技术的堆砌。

没有什么问题是不能通过增加一个抽象层解决的，如果不能，就再加一层。

我们在进行架构设计等的时候，也应当从模式出发，而非从特定技术/中间件出发。比如，就服务发现和路由——如何对服务进行注册，从而抽象服务的物理地址；如何让消费微服务的客户端能够定位和路由到相应微服务——这个来说，不应当从特定技术，如 Spring Gateway，Nacos，Eureka 等出发，而应当在更抽象即模式的层面上研究，问题和需求究竟是什么，怎样的设计是松散耦合的，可维护可配置的，这些技术/中间件是如何应用这个模式的，有什么优点和缺点……这样既可以从特定技术中解放出来，也给予我们选择最合适的方案的可能性。

各种云计算模型（XaaS）

微服务必定和云脱不了关系，这里介绍了常见的云计算模型，即各种 XaaS（anything as a service）以及用户和服务提供商所需要负担的职责，即开发者使用该种云平台时需要关心的东西——

可以认为最底层的两个即”Networking, storage, and servers”和”Data center”为真正的硬件设施。

• Infrastructure as a Service (IaaS，基础设施即服务） ——服务提供商负责提供一定基础设施，让用户能够访问诸如服务器，存储和网络等计算资源。在这个模型里，用户需要负责一切和基础设施以及应用的伸缩性相关的东西，IaaS 平台包括 AWS 的 EC2，Azure Virtual Machines，Google Compute Engine，和 Kubernetes。可以认为 IaaS 就相当于是租用了一个云服务器，需要自己管理操作系统之上的所有部分。

• Container as a Service (CaaS，容器即服务） ——基于容器的虚拟化的形式，用户可以把微服务部署在一个轻量的，可携带（绿色）的虚拟容器如 Docker 中。云服务提供商负责运行容器，以及提供所有关于构建，部署，监控和伸缩容器的工具。CaaS 相较于 IaaS，用户不需关心操作系统的细节，且治理工具由云服务提供商提供，因而维护和伸缩起来较 IaaS 更容易。CaaS 平台包括谷歌的 GKE，亚马逊的 ECS（阿里的云服务器也叫这个名字，但阿里的是 IaaS，funny）。这本书主要使用 CaaS，我也认为 CaaS 在复杂性和定制性之间取得了一个很好的平衡。

• Platform as a Service (PaaS，平台即服务） ——服务器提供商提供平台和环境来让用户专注于应用的开发，执行和维护。用户可以完全不用关心物理的基础设施。PaaS 的缺点在于这样部署的应用是和平台提供商耦合的，必须利用平台提供商提供的 API 或工具来交互计算资源，因而移植性欠佳。PaaS 平台包括 Google App Engine，Cloud Fondry，Heroku 和 AWS Elastic Beanstalk。

• Function as a Service (FaaS，功能即服务） ——也称为无服务器架构，用户只需关心服务的开发，其余任何东西都交给云服务商了，应用将运行在服务提供商提供的运行时引擎中。FaaS 平台包括 AWS（Lambda），Google Cloud Function 和 Azure functions，Cloudflare 的 worker 也是 FaaS（还免费呢，好玩）。

• Software as a Service (SaaS，软件即服务） ——用户使用一个特定的应用而不需要部署或维护。用户租了就用，其他什么都关心不了。这像是某种低代码之类的东西。

微服务面临的问题

在接触到具体的模式前，应当先知道开发微服务架构应用时会遇到什么问题——

1. 服务粒度——如何正确分解业务领域到一堆微服务中，使其中每个都有合适的职责？职责的粒度若太粗，在不同业务问题领域上有重叠，就会让其难以维护和修改；若太细，则会增加应用整体的复杂度，让服务变成愚蠢的数据抽象层，除了对数据的访问外没有别的逻辑。（这话真难翻译！）

2. 通讯协议——服务和客户端/服务间的通信同步还是异步？轻量级还是重量级？通用还是自定义？

3. 接口设计——调用服务的实际接口该如何设计？

4. 服务的配置管理——如何优雅和方便地管理微服务的配置，使不需要修改源代码就可以适应不同环境？

5. 服务间的事件处理——如何使用事件对微服务进行解耦，从而最小化服务间硬编码（直接调用？）的相互依赖？

也需要意识到，微服务不是银弹，它和单体架构相比，也只能说是另一种架构风格而已，有自己所适用之处，也有自己的缺点，带来自己的复杂度。

The more distributed a system is, the more places it can fail.

书中介绍道，微服务是无状态（stateless）的。为何要设计成无状态？为了能方便横向扩展，即增加一个微服务的实例数量时不会有任何影响。考虑一个简单情形——维护一个对接口访问量的计数器：如果该状态维护在每个实例（进程）的内存中， 统计完全的计数值就需要统计每一个实例中的值，徒增了复杂度，而这种复杂度完全可以通过 Redis 或数据库等来避免。

Spring Cloud

该书书名已经指明，其将以 Spring 作为出发点来介绍微服务。Spring Cloud 为微服务开发提供了完全的支持，对各种模式提供了相应的中间件的集成，且仅通过简单注解便可快速起步，因此非常适合进行学习。

Spring Cloud 当然不是唯一选择，微服务使用轻量级的通讯协议，这使使用不同语言进行开发成为可能。我在网络上看到过。Net Core + Nacos + Spring Cloud 这样的组合。但 Spring 肯定是最优先的选择，毕竟 JVM 这边才是主流。