微服务架构介绍
单体架构：将全部都打包在一起，单体架构的性能是最高的，冗余小。但是debug困难，模块之间相互影响，使用人数过多在分工和流程上会出问题。
垂直业务架构：每个业务还是一个架构，依旧存在单体架构的缺陷。
分布式架构：抽出与业务无关的公共模块，独立。但是服务模块的bug会导致瘫痪，调用复杂冗余大。
SOA架构：有服务注册的功能。缺点是从上而下设计，重构困难。
微服务架构：开发效率高，业务独立设计，自下而上，障碍隔离。缺点是，治理和运维的难度会增加。
微服务架构核心要素：服务治理、可观测性、安全。
可观测性：日志，监控，报警，追踪
微服务架构基本概念
服务：一组具有相同逻辑的运行实体（运行同一段代码） 实例（instance）：一个服务中，每个运行实体即一个实例 集群（cluster）：包含多个实例
服务间通信：对于单体服务中，不同模块通信只是简单的函数调用，对于微服务，服务间通信意味着网络传输（比如http）。
在代码中如何制定一个目标服务的地址？新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
服务发布（deployment）：让一个服务升级运行新代码的过程。 服务发布的难点：服务不可用，服务抖动，服务回滚。
蓝绿部署：将服务分为蓝绿集群，将流量导入到一个集群，然后升级另一部分。再换一边升级。简单稳定，但需要两倍的资源。 灰度发布（金丝雀发布）
流量治理：在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行管理。
重试的意义：降低错误率，降低长尾延时，容忍暂时性错误，避免故障。
重试的难点：重试风暴（解决方法；设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值。方法2：限制每层都发生重试，理想情况下只有最下一层发生重试）
