微服务架构中职能团队的划分
传统单体架构将系统分成具有不同职责的层次，对应的项目管理也倾向于将大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队与数据存取ORM团队、DBA团队等。
根据康威定律，团队的交流机制应该与架构设计机制相对应。因此，在微服务架构下，职能团队的划分方法是我们首先要考虑的一个核心要素。
微服务架构按照业务的功能进行划分，每个单一的业务功能叫作一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互UI设计师、后台服务开发人员、DBA、运营和运维人员。
微服务的去中心化治理
微服务架构倡导去中心化的服务管理和治理，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计。在笔者工作的支付平台服务化建设中，第1层SOA服务化采用Dubbo框架进行定制化，如果Dubbo服务化出现了大面积的崩溃，则服务化体系会切换到点对点的hessian远程调用，这被称为服务化降级，降级后点对点的hessian远程调用时没有中心化节点，整体上符合微服务的原理。
微服务的交互模式
本节介绍微服务之间交互的通用设计模式，这些设计模式对微服务之间的交互定义契约，服务的生产者和调用者都需要遵守这些契约，才能保证微服务不出问题。
1. 读者容错模式
2. 消费者驱动契约模式
服务契约分为：提供者契约、消费者契约及消费者驱动的契约，它从期望与约束的角度描述了服务提供者与服务消费者之间的联动关系。
- 提供者契约：是我们最常用的一种服务契约，顾名思义，提供者契约是以提供者为中心的，提供者提供了什么功能和消息格式，各消费者都会无条件地遵守这些约定，不论消费者实际需要多少功能，消费者接受了提供者契约时，都会根据服务提供者的规则来使用服务。
- 消费者契约：是对某个消费者的需求进行更为精确的描述，在一次具体的服务交互场景下，代表消费者需要提供者提供功能中的哪部分数据。消费者契约可以被用来标识现有的提供者契约，也可以用来发现一个尚未明确的提供者契约。
- 消费者驱动的契约：代表服务提供者向其所有当前消费者承诺遵守的约束。一旦各消费者把自己的具体期望告知提供者，则提供者无论在什么时间和场景下，都不应该打破契约。
在现实的服务交互设计中，上面这三种契约是同时存在的，笔者所在的支付平台里，交易系统在完成一笔支付后，需要到账务系统为商户入账，在这个过程中，服务契约表现如下。
- 生产者契约：账务系统提供Dubbo服务化接口，参数为商户账户ID、入账订单号和入账金额。
- 消费者契约：账务系统返回DTO，包含商户账户ID、入账订单号、入账金额、入账时间、账务流水号、入账状态等，而交易系统只需使用其中的入账订单号和入账状态。
- 消费者驱动的契约：为了保证资金安全，交易系统作为入账的发起者向账务提出要求，需要账务做幂等和滤重处理，对重复的入账请求进行拦截；账务系统在接受这个契约后，即使将来有任何改变，也不能打破这个限制，否则就会造成资金的损失，这在金融系统中是最严重的问题。
服务之间的交互需要使用的三种服务契约如图1-10所示。
从图1-10可以看到，服务提供者契约是服务提供者单方面定下的规则，而一个消费者契约会成为提供者契约的一部分，多个服务消费者可以对服务提供者提出约束，服务提供者需要在将来遵守服务消费者提出的契约，这就是消费者驱动的契约。
3. 去数据共享模式
在实践的过程中，有些方案的设计使用缓存或者数据库作为两个微服务之间的纽带，在业务流程的处理过程中，为了处理简单，前一个服务将中间结果存入数据库或者缓存，下一个服务从缓存或者数据库中拿出数据继续处理。处理流程如图1-11所示。
这种交互流程的缺点如下。
- 使得微服务之间的交互除了接口契约，还存在数据存储契约。
- 上游的数据格式发生变化时，可能导致下游的处理逻辑出现问题。
- 多个服务共享一个资源服务，对资源服务的运维难以划清职责和界限。
- 在做双机房独立部署时，需要考虑服务和资源的路由情况，跨机房的服务调用不能使用独立的资源部署模式，因此难以实现服务自治。
微服务的分解和组合模式
使用微服务架构划分服务和团队是微服务架构实施的重要一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。
在微服务架构的需求分析和架构设计过程中，通常是用领域的动词和名词来划分微服务的，例如，对于一个电商后台系统，可以分解为订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等子系统，每个名词和动词都可以是一个微服务，将这几个微服务组合在一起，就实现了电商平台用户购买商品的整个业务流。
这样拆分以后，系统具有敏捷性、灵活性、可伸缩性等，拆分后有多个高度自治的微服务，那么以什么方式组合微服务呢？
1. 服务代理模式
服务代理模式是最简单的服务组合模式，它根据业务的需求选择调用后端的某个服务。在返回给使用端之前，代理可以对后端服务的输出进行加工，也可以直接把后端服务的返回结果返回给使用端。
在笔者工作的微服务化架构平台下，经常会使用这种模式，典型的案例是做平滑的系统迁移，通常经历如下4个阶段。
- 在新老系统上双写。
- 迁移双写之前的历史遗留数据。
- 将读请求切换到新系统。
- 下调双写逻辑，只写新系统。
服务代理模式常常应用到第3步，一般会对读请求切换设计一个开关，开关打开时查询新系统，开关关闭时查询老系统。
2. 服务聚合模式
服务聚合模式是最常用的服务组合模式，它根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。
这样的设计原则有如下好处。
- 三个独立的子服务可以各自独立开发、敏捷变更和部署。
- 聚合服务封装下层的业务处理服务，由三个独立的子服务完成数据持久化等工作，项目结构清晰明了。
- 三个独立的子服务对于其他使用方仍然可以重用。
考虑到本节开头的例子，在对微服务进行拆分时，将电商后台系统大致拆分成订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等微服务，那么电商平台的前端应用就是后端各个微服务的一个最大的聚合服务，前端应用通过调用商品和商品目录显示商品列表，提供给用户选择商品的功能，用户选择商品后增加商品到购物车，在用户从购物车结算时，调用交易系统完成交易和支付等。
另外，聚合服务也可以是一个纯后台服务，通过聚合对使用方输出组合的服务，例如在上面的电商系统案例中，在用户选择结算后，系统调用交易，交易系统会调用库存系统锁库存，然后创建交易订单，引导用户去支付，支付成功后扣减库存，最后通过发票服务开具电子发票。
3. 服务串联模式
服务串联模式类似于一个工作流，最前面的服务1负责接收请求和响应使用方，串联服务后再与服务1交互，随后服务1与服务2交互，最后，从服务2产生的结果经过服务1和串联服务逐个处理后返回给使用方，如图1-17所示。
服务串联模式之间的调用通常使用同步的RESTful风格的远程调用实现，注意，这种模式采用的是同步调用方式，在串联服务没有完成并返回之前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，因此在这种模式下不建议服务的层级太多，如果能用服务聚合模式代替，则优先使用服务聚合模式，而不是使用这种服务串联模式。
相对于服务聚合模式，服务串联模式有一个优点，即串联链路上再增加一个节点时，只要不是在串联服务的正后面增加，那么串联服务是无感知的。
在上面提及的电商案例中，UI前端应用调用交易，交易调用商品库存系统锁定库存和扣减库存，使用的就是服务串联模式。
4. 服务分支模式
服务分支模式是服务代理模式、服务聚合模式和服务串联模式相结合的产物。
在实际的业务平台建设中，由于业务的复杂性，抽象的微服务可能有多层的依赖关系，依赖关系并不会太简单，经常呈现树形的分支结构。
支付服务对接两个外部的支付网关，都要经过各自的支付渠道网关，同时支持账户余额支付，这个支付服务其实就是一个分支模式，在实际项目中这种服务分支模式很多。
某天，基础服务6的8台机器中的1台宕机，按照常理，大家都认为只影响其中1/8的流量，而统计结果显示影响的业务结果竟然大于1/8。
仔细思考，造成这个结果的原因是调用链上有多个层次重复调用了基础服务，导致基础服务挂掉时影响的流量有累加效果，具体计算如下。
假设进入系统的流量为n，调用链从服务3开始调用服务6，服务3有1/8的流量失败，这时剩下的成功的流量为7/8 ×n，剩下的成功的流量继续走到服务5，服务5再次调用服务6，又有1/8的流量失败，剩下7/8 × 7/8× n。
假设基础服务资源池中的机器个数为i，一次挂掉的机器个数为j，一个调用链中调用x次基础服务，那么正确处理的流量的计算公式为：
假设允许的可用性波动率为a，求出底层服务一次宕机1台时最少应该配置的机器数为：
对公式进行转换：
由于一次只允许一台机器宕机：
所以得出需要设置的机器数量i为：
对于上面的案例，每次最多允许基础服务6宕机1台，在这种情况下需要保持可用性的波动率小于25%，一共有两层服务依赖基础服务6，通过上述公式计算得出：
i > 7.5
结果，至少为服务6部署9台机器，这样在1台机器宕机时，对可用性的波动性影响控制在25%以内。
5. 服务异步消息模式
前面的所有服务组合模式都使用同步的RESTful风格的同步调用来实现，同步调用模式在调用的过程中会阻塞线程，如果服务提供方迟迟没有返回，则服务消费方会一直阻塞，在严重情况下会撑满服务的线程池，出现雪崩效应。
典型的案例就是在电商系统中，交易完成后向物流系统发起消息通知，通知物流系统发货，如图1-24所示。
6. 服务共享数据模式
服务共享数据模式其实是反模式，在1.3.3节中提出了去数据共享模式，由于去掉了数据共享，所以仅仅通过服务之间良好定义的接口进行交互和通信，使得每个服务都是自治的，服务本身和服务的团队包含全角色栈的技术和运营人员，这些人都是专业的人做专业的事，使沟通在团队内部解决，因此可以使效率最大化。
然而，在下面两种场景下，我们仍然需要数据共享模式。
- 单元化架构
一些平台由于对性能有较高的要求，所以采用微服务化将服务进行拆分，通过网络服务进行通信，尽管网络通信的带宽已经很宽，但是还会有性能方面的损耗，在这种场景下，可以让不同的微服务共享一些资源，例如：缓存、数据库等，甚至可以将缓存和数据在物理拓扑上与微服务部署在一个物理机中，最大限度地减少网络通信带来的性能损耗，我们将这种方法称为“单元化架构”。
- 遗留的整体服务
对于历史遗留的传统单体服务，我们在重构微服务的过程中，发现单体服务依赖的数据库表耦合在一起，对其拆分需要进行反规范化的处理，可能会造成数据一致性问题，在没有对其完全理解和有把握的前提下，会选择保持现状，让不同的微服务暂时共享数据存储。
微服务的容错模式
1. 舱壁隔离模式
这里用航船的设计比喻舱壁隔离模式，若一艘航船遇到了意外事故，其中一个船舱进了水，则我们希望这个船舱和其他船舱是隔离的，希望其他船舱可以不进水，不受影响。在微服务架构中，这主要体现在如下两个方面。
1）微服务容器分组
笔者所在的支付平台应用了微服务，将微服务的每个节点的服务池分为三组：准生产环境、灰度环境和生产环境。准生产环境供内侧使用；灰度环境会跑一些普通商户的流量；大部分生产流量和VIP商户的流量则跑在生产环境中。这样，在一次比较大的重构过程中，我们就可以充分利用灰度环境的隔离性进行预验证，用普通商户的流量验证重构没有问题后，再上生产环境。
2）线程池隔离
在微服务架构实施的过程中，我们不一定将每个服务拆分到微小的力度，这取决于职能团队和财务的状况，我们一般会将同一类功能划分在一个微服务中，尽量避免微服务过细而导致成本增加，适可而止。
2. 熔断模式
可以用家里的电路保险开关来比喻熔断模式，如果家里的用电量过大，则电路保险开关就会自动跳闸，这时需要人工找到用电量过大的电器来解决问题，然后打开电路保险开关。在这个过程中，电路保险开关起到保护整个家庭电路系统的作用。
3. 限流模式
服务的容量和性能是有限的，在第3章中会介绍如何在架构设计过程中评估服务的最大性能和容量，然而，即使我们在设计阶段考虑到了性能压力的问题，并从设计和部署上解决了这些问题，但是业务量是随着时间的推移而增长的，突然上量对于一个飞速发展的平台来说是很常见的事情。
有如下几种主流的方法实现限流。
1）计数器
通过原子变量计算单位时间内的访问次数，如果超出某个阈值，则拒绝后续的请求，等到下一个单位时间再重新计数。
在计数器的实现方法中通常定义了一个循环数组（见图1-30），例如：定义5个元素的环形数组，计数周期为1s，可以记录4s内的访问量，其中有1个元素为当前时间点的标志，通常来说每秒程序都会将前面3s的访问量打印到日志，供统计分析。
我们将时间的秒数除以数组元素的个数5，然后取模，映射到环形数组里的数据元素，假如当前时间是1 000 000 002s，那么对应当前时间的环形数组里的第3个元素，下标为2。
当前时间为1 000 000 002s，对应的计数器在第3个元素，下标为2，当前请求是在这个时间周期内的第1个访问请求，程序首先需要对后一个元素即第4个元素，也就是下标为3的元素清零；在1 000 000 002s内，任何一个请求如果发现下标为3的元素不为0，则都会将原子变量3清零，并记录清零的时间。
这时程序可以对第3个元素即下标为2的元素，进行累加并判断是否达到阈值，如果达到阈值，则拒绝请求，否则请求通过；同时，打印本次及之前3秒的数据访问量，打印结果如下。
当前：1次，前1s：302次，前2s：201次，前3s：518次
然而，如果当前秒一直没有请求量，下一秒的计数器始终不能清零，则下一秒的请求到达后要首先清零再使用，并更新清零时间。
2）令牌筒
令牌筒是一个流行的实现限流的技术方案，它通过一个线程在单位时间内生产固定数量的令牌，然后把令牌放入队列，每次请求调用需要从桶中拿取一个令牌，拿到令牌后才有资格执行请求调用，否则只能等待拿到令牌再执行，或者直接丢弃。
3）信号量
限流类似于生活中的漏洞，无论倒入多少油，下面有漏管的流量是有限的，实际上我们在应用层使用的信号量也可以实现限流。
使用信号量的示例如下：
public class SemaphoreExample {
private ExecutorService exec = Executors.newCachedThreadPool();
public static void main(String[] args) {
final Semaphore sem = new Semaphore(5);
for (int index = 0; index < 20; index++) {
Runnable run = new Runnable() {
public void run() {
try {
// 获得许可
sem.acquire();
// 同时只有5个请求可以到达这里
Thread.sleep((long) (Math.random()));
// 释放许可
sem.release();
System.out.println("剩余许可：" + sem.availablePermits());
} catch (InterruptedException e) {
e.printStackTrace();
}
}
};
exec.execute(run);
}
exec.shutdown();
}
}4. 失效转移模式
若微服务架构中发生了熔断和限流，则该如何处理被拒绝的请求呢？解决这个问题的模式叫作失效转移模式，通常分为下面几种。
- 采用快速失败的策略，直接返回使用方错误，让使用方知道发生了问题并自行决定后续处理。
- 是否有备份服务，如果有备份服务，则迅速切换到备份服务。
- 失败的服务有可能是某台机器有问题，而不是所有机器有问题，例如OOM问题，在这种情况下适合使用failover策略，采用重试的方法来解决，但是这种方法要求服务提供者的服务实现了幂等性。
微服务的粒度
在服务化系统或者微服务架构中，我们如何拆分服务才是最合理的？服务拆分到什么样的粒度最合适？
按照微服务的初衷，服务要按照业务的功能进行拆分，直到每个服务的功能和职责单一，甚至不可再拆分为止，以至于每个服务都能独立部署，扩容和缩容方便，能够有效地提高利用率。拆得越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线。
然而，拆得太细会导致系统的服务数量较多，相互依赖的关系较复杂，更重要的是根据康威定律，团队要响应系统的架构，每个微服务都要有相应的独立、自治的团队来维护，这也是一个不切实际的想法。
因此，这里倡导对微服务的拆分适可而止，原则是拆分到可以让使用方自由地编排底层的子服务来获得相应的组合服务即可，同时要考虑团队的建设及人员的数量和分配等。
有的公司把每个接口包装成一个工程，或者把每一次JDBC调用包装成一个工程，然后号称是“微服务”，最后有成百上千的微服务项目，这是不合理的。当然，有的公司把一套接口完成的一个粗粒度的流程耦合在一个项目中，导致上层服务想要使用这套接口中某个单独的服务时，由于这个服务与其他逻辑耦合在一起，所以需要在流程中做定制化才能实现使用方使用部分服务的需求，这也是不合理的，原因是服务粒度太粗。