一、微服务架构介绍
（1）系统架构的演进历史
单体架构: All in one process
垂直应用架构:按照业务线垂直划分
分布式架构:抽出与业务无关的公共模块
SOA架构:面向服务
微服务架构:彻底的服务化
（2）微服务架构概览
网关
服务配置和治理
链路追踪和监控
（3）微服务架构的三大要素
· 服务治理
服务注册
服务发现
负载均衡
扩缩容
流量治理
稳定性治理
·可观测性
日志采集
日志分析
监控打点
监控大盘
异常报警
链路追踪
·安全
身份验证
认证授权
访问令牌
审计
传输加密
黑产攻击
二、微服务架构原理及特征
（1）微服务架构中的基本概念及组件
服务:一组具有相同逻辑的运行实体
实例:一个服务中的每个运行实体
实例与进程的关系:没有必然对应关系，一般一对一或者一对多
常见的实例承载形式:进程、VM、k8s pod......
（2）服务间通信
微服务之间通过网络进行通信
常见的通信协议包括 HTTP、RPC
（3）服务注册及服务发现
基本问题:服务间调用中，如何指定下游服务实例的地址？
简单方案:
直接指定 ip:port？
没有任何动态能力
有多个实例下游实例怎么办？
使用 DNS？
本地 DNS 存在缓存，导致延迟
DNS 没有负载均衡
不支持服务探活检查
DNS 不能指定端口
服务注册发现
新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
旧服务实例下线前，从服务注册中心删除该实例，下线流量
新服务实例上线后，在服务注册中心注册该实例，上线流量
微服务流量特征
统一网关入口
外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
三、核心服务治理功能
（1）服务发布：让一个服务升级运行新的代码的过程
服务发布难点:
服务不可用
服务抖动
服务回滚
蓝绿部署:
将服务分成两个部分，分别先后发布
简单、稳定
但需要两倍资源
灰度发布（金丝雀发布）:
先发布少部分实例，接着逐步增加发布比例
不需要增加资源
回滚难度大，基础设施要求高
（2）流量治理
流量控制：在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制
控制维度：
地区维度
集群维度
实例维度
请求维度
负载均衡
Round Robin
Random
Ring Hash
Least Request
稳定性治理
限流:限制服务处理的最大 QPS，拒绝过多请求
熔断:中断请求路径，增加冷却时间从而让故障实例尝试恢复
过载保护:在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
降级:服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
四、字节跳动服务治理实践
（1）请求重试的意义
本地函数调用：通常没有重试意义
远程函数调用
网络抖动、下游负载高、下游机器宕机......
重试是有意义的，可以避免偶发性的错误，提高 SLA
重试的意义
降低错误率
降低长尾延时
容忍暂时性错误
避开下游故障实例
（2）请求重试的难点
幂等性:POST请求可以重试吗？
重试风暴:随着调用链路的增加，重试次数呈指数级上升
超时设置:假设调用时间一共1s，经过多少时间开始重试？
（3）重试策略
限制重试比例:设定一个重试比例阈值（例如 1%），重试次数占所有请求比例不超过该阈值
防止链路重试:返回特殊的 status code，表示“请求失败，但别重试”
Hedged Requests:对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应
（4）重试效果验证
字节跳动重试组件能够极大限制重试发生的链路放大效应
五、课后思考题
1.结合 CAP 等原理，思考微服务架构有哪些缺陷？
·一致性：由于微服务架构中的服务之间采用异步通信方式，保证数据一致性变得更加复杂。在网络分区或故障发生时，需要权衡一致性、可用性和分区容忍性。
·可用性：微服务架构中的服务数量增多，依赖关系复杂，一旦某个服务不可用，可能会影响整个系统的可用性。
·性能：服务之间的通信开销较大，特别是跨服务的远程调用可能会引入额外的延迟，从而影响系统的性能。
2.微服务是否拆分得越“微”越好？为什么？
微服务不一定越“微”越好。微服务的拆分应该根据实际业务需求和技术复杂度来决定。如果将每个功能或模块都拆分成微服务，会导致服务数量过多，服务之间的通信和管理成本增加，维护和部署变得困难。因此，合理的拆分粒度应该是在满足业务需求的前提下，尽量避免服务数量过多，同时考虑服务的独立性和可扩展性。
3.Service Mesh 这一架构是为了解决微服务架构的什么问题？
Service Mesh这一架构是为了解决微服务架构中的服务间通信、可观察性和治理等问题。在微服务架构中，服务之间的通信变得复杂，需要解决服务发现、负载均衡、熔断、重试等问题。Service Mesh 提供了一个专门的基础设施层，将这些通用功能抽离出来，并通过代理（例如 Envoy）实现服务之间的通信控制和管理。
4.有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？
可能存在，这可以通过使用容器化技术和自动化部署工具等来实现。例如，将单体应用拆分为多个模块，并使用容器化技术将每个模块独立部署。这样可以获得类似微服务的灵活性和可扩展性，同时使用自动化工具可以简化开发上线和运维的体验。但需要注意的是，这种方式可能会牺牲一部分微服务架构所带来的优势，如独立部署、独立扩展和自治性等。因此，在选择适合的架构时，需要根据具体需求和情况进行权衡和取舍。
