系统架构演变概述

系统架构的演变历史，可以认为是从单体架构->垂直应用架构->分布式架构->SOA架构->微服务架构，整体看来就是服务的拆分粒度越来越细粒度了，从按业务拆分一直到服务拆分，这与信息技术的广泛使用、互联网的发展紧密相关，因为拆分就是为了方便分工提高开发效率以及故障隔离。当然也带来了更多挑战，如服务治理、运维的难度大大提高、对各服务的观测、安全保证等，在业务开发之外也需要更多的工作去保证一个微服务系统的可靠运行。(当然新技术的发展也养活了一批开拓技术的程序员:))

服务间通信

对于单体应用，业务模块的相互调用就是函数调用。而在微服务中，是RPC网络请求。

而为了知道要调用哪个服务，以及哪些服务可以调用，需要服务注册与发现。如果用硬编码，则不能做到运行时动态修改。使用DNS，则有因缓存导致的延时问题，且不支持负载均衡、只能做到修改IP而不能修改端口，还不支持心跳探活等高级特性。

所以就要引入一个统一的服务注册中心中间件，负责管理服务集群的服务名到服务实例的映射。调用方从注册中心中获得可用的被调用方，然后才去调用。启停服务时均会与注册中心交互保证即时更新集群状态。

微服务项目的流量特征

系统整体通过一个网关入口对外提供服务，内部服务通过RPC相互调用，链路呈网状。

服务发布

即更新一个服务的源码并再次运行，起到升级作用的过程。

上线项目对高可用性的要求对于服务发布提出了挑战。因为服务发布不是瞬间完成的，是需要一定时间，而且更新中的服务肯定是下线的。

在单体项目中，服务的更新肯定会导致系统的不可用。即使有两个相同服务，也会在更新第一个的过程中因为将流量全部传到第二个服务，导致服务抖动。更有甚者，在服务更新后发现有bug，需要马上回滚，带来更复杂的问题。

常用解决方案：

蓝绿部署，即再申请一倍的资源再开一个同样的实例对外照常提供服务，然后把要升级的实例下线升级，升级好之后直接将流量从刚刚申请的实例上切换过来。简单、稳定，但需要两倍资源，在切换的过程中其实也容易出现抖动问题。
灰度发布(金丝雀发布)。金丝雀就是指矿工下矿前放金丝雀探查一下是否存在有毒气体。同理，服务的更新也可以存在“探”的过程。这个过程会同时让升级后实例和旧实例同时对外提供服务，在显示升级后实例可以正常提供服务后，继续将其他旧实例逐个替换。但是不断切换流量需要比较复杂的管理机制，而且回滚也比较复杂。

流量治理

根据现实地区分配流量
将少量流量分给测试服务已实现线上测试
对于处理能力较差的老机器，分配较少的流量
对于特殊用户的请求单独测试

负载均衡

稳定性治理

现实世界要比程序复杂许多，总会导致服务出现问题。

限流。为了防止服务器被突增的海量请求打挂掉，将处理能力之外的请求直接拒绝。在被请求方用了一个请求计数器。
熔断。在请求方加了一个熔断器，如果对同一个被请求实例重试的多次请求都失败，则熔断器会关闭，下一次还请求这个实例时，因为熔断器已关闭，所以直接返回请求失败。
过载保护。限流是根据请求计数，过载保护则是被请求实例监听本机情况。如果被请求实例存在如CPU过载，则他自身也会开启一个机制，拒绝掉一部分请求，尽量避免本机被打挂。在被请求方用了一个负载监听器。
降级。在被请求方加一个请求筛选器，只对重要的请求者提供服务，其他的则直接返回拒绝处理。

字节实践

重试可以避免偶发的错误。

但是也有难点。因为重试就是将同一个请求在timeout后发送多次。

幂等性。这就要求接口满足幂等性。如果一个请求会让balance=balance-10，那么三次重试就可能会扣除三次余额。
重试风暴。在一条链路上的重试次数会被指数级放大。应对策略是为整条链路设置一个最大的重试次数，或者重试次数不超过请求次数的几分之几。或者，如果中间链路都没问题，只是最后一个有问题，那么这个错误不应该被传播回去，而是直接告知前一个节点，出错了，但不是你的问题，不要让前面的节点重试了。

2024字节青训营笔记-微服务与企业级后端架构