微服务本质上是一种设计模式，一种指导思想。在落地实现时有多种技术选型。在一些文献中也会对其概念、思想、以及与SP或单体服务做些一些对比。这些内容在笔者看来只能是靠个人的理解和悟性来归纳总结，所以就不在此进行描述了。本文会贴合技术来描述下微服务的一些基础知识点。

一、基础

完整的架构如下图所示：

1.1、服务注册发现

服务注册就是维护一个登记簿，它管理系统内所有的服务地址。当新的服务启动后，它会向登记 簿交待自己的地址信息。服务的依赖方直接向登记簿要 Service Provider 地址就行了。当下用于服 务注册的工具非常多 ZooKeeper，Consul，Etcd, 还有 Netflix 家的 eureka 等。服务注册有两种 形式:客户端注册和第三方注册。

1.1.1、注册

客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下 线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心 负责(这个过程叫探活)。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一 套注册逻辑。

技术上由一个独立的服务 Registrar 负责注册与注销。当服务启动后以某种方式通知 Registrar， 然后 Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不 可用时，向注册中心注销服务。这种方式的缺点是 Registrar 必须是一个高可用的系统，否则注册 工作没法进展。

1.1.2、客户端发现

客户端发现是指客户端负责查询可用服务地址，以及负载均衡的工作。这种方式最方便直接，而 且也方便做负载均衡。再者一旦发现某个服务不可用立即换另外一个，非常直接。缺点也在于多 语言时的重复工作，每个语言实现相同的逻辑。

1.1.3、服务端发现

服务端发现需要额外的 Router 服务，请求先打到 Router，然后 Router 负责查询服务与负载均衡。 这种方式虽然没有客户端发现的缺点，但是它的缺点是保证 Router 的高可用。

注意：注册中心只管发现，在实际调用过程中是P2P直连调用的，并不经过注册和寻址服务器。

1.2、管理功能

一般会有分组、上下线、流量转移等，这里只说两个常见的功能。

1.2.1、服务跟踪

随着微服务数量不断增长，需要跟踪一个请求从一个微服务到下一个微服务的传播过程， Spring Cloud Sleuth 正是解决这个问题，它在日志中引入唯一 ID，以保证微服务调用之间的一致性，这 样你就能跟踪某个请求是如何从一个微服务传递到下一个。

1.2.2、服务限流/熔断

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个 系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不 可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到 许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序 不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU 时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经 修正，应用程序会再次尝试调用操作。

二、关于API网关

在RPC调用中，网关其实是一个可选的组件，如果按服务对象来分的话，大体可以理解为：rpc内网调用、API适用于外网调用，各有侧重。这里只描述下其概念。API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的 Facade 模式很像。API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有 其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一 个适应当前架构的 API Gateway。

网关并不只是HTTP协议的，有些rpc框架也同时带了协议转换和网关功能，但不是太常用。

三、线程模型

下图是一种典型的rpc通信线程模型的设计，主要分为业务线程池和IO线程池，如下图所示：

四、从单体服务到微小服务的改造建议

实施建议

• 最小修改：制定对现有系统的修改保护策略，最小范围修改老系统；新功能在新系统上开发；
• 功能剥离：剥离核心功能并服务化，部分功能采用代理方式到新服务中；
• 数据解耦：基于2的改造后，部分数据已经做到了解耦；
• 数据同步：双写或双读机制；
• 迭代替换：持续发布；在上述过程中，可以开发一套代码生成工具，使开发人员只关注业务本身的开发，而不关注基础服务的开发。还可以建立一套快速开发模板。

老系统的改造（选隔离再拆分）

不要做一步到位，推倒重来。因为这样做风险比较大，也有可能会失败。可能的方式是在遗留应用程序周围逐步开发新的应用程序来实现应用程序的现代化。这个过程可能会持续很长一段时间，也可能永远不会完成，所以在实施时可以：

• 迟早并且频繁地体现出价值：可以先移植价值最高的部分，这样价值很容易体现出来
• 尽可能少对单体做出修改：不是不可以修改可以采取适当的设计手段隔离后再修改
• 部署基础设施：持续交付的自动化流程
• 将新功能实现为服务，可以有效阻止单体程序的发展，快速获得认可；
• 隔离表现层和后端
• 通过将功能提取到服务中来分解单体，要基于DDD分析。

更具体的建议如下：

• 在迁移到微服务架构前，要做好充分的评估，这个评估可以是多维度的，比如发布过程等；
• 开发一个绞杀者程序，围绕现有单体应用构建微服务，其目的是为了快速证明价值，得到业务团队的支持；
• 在具体实施时，可以以新功能为试点；
• 分离表现层和端，目的是拆分为两个独立的单体结构；
• 选价值最大的功能迁移到微服务中；
• 采用适配器的方式做好新服务与原有单体之间的交互也称集成胶水代码，其中包含单体的入站和出站适配器，主要是改造单体上面加适配器；也可以用防腐层；
• 在数据库层面统一，可行的做法是保持原数据库结构不变，然后把迁移服务的数据复制回原单体服务；
• 仔细考虑设计服务的提取顺序，以避免在单体中实现大范围的saga类型的事物补偿；
• 安全方面的问题，可行的方式是通过api gateway的方式转发实现；