这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
微服务是一个开发应用的形式，我理解微服务，通俗来说就是可将大型应用分解成多个独立的组件，其中每个组件都有各自的责任领域。 在处理一个用户请求时，基于微服务的应用可能会调用许多内部微服务来共同生成其响应。
历史
-
单体架构：性能最高，冗余最小，但是debug困难，模块相互影响，分工复杂，开发流程复杂。
-
垂直应用架构：按照业务线垂直划分
优势：业务独立开发；烈士：每个业务还是单体，有很多重复性工作。
-
分布式架构：抽取出与业务无关的公共模块（服务层）
-
SOA架构：面向服务（服务注册与发现）
重构困难，太复杂了。
-
微服务架构：
彻底的服务化。
优势：开发效率很高，各个业务之间独立，自下而上，故障隔离。
劣势：治理、运维难度，观测挑战，安全性。
服务注册与发现
新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
服务下线：先在服务中心，删除准备下线服务中心的ip，等没有流量了再开始下线实例。
上线：启动服务实例，健康检查，服务注册。
服务部署
-
蓝绿部署：两倍资源切换。
-
灰度发布（先在部分实例上发布，若没有问题，才逐步放开）。
重试
-
本地异常没必要重试，远程调用异常有必要重试（特别是在网络调用中）。
-
重试的难点：幂等性，重试风暴（防止链路重试、重试倍数限制），超时设置。
RPC
-
RPC的论文
不同机器（同一机器）的进程间通信
-
RPC过程
生成代码 -> 编解码 -> 通信协议 -> 网络传输
RPC的优缺点
RPC有利于单一职责，有利于分工协作和运维开发。
可拓展性强，资源使用率更优秀。
故障隔离性强。
RPC的问题，包括：服务器宕机，对方如何处理；如何保证消息的可达性。
