这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
微服务架构介绍
单体 -> 垂直应用 -> 分布式 -> SOA -> 微服务
随着架构的演变，新架构的开发效率与独立性随之提高，故障隔离，自下而上的设计对业务开发人员来说较为友好；但是随之而来的就是治理与运维的问题。
核心要素
- 服务治理：服务注册，发现；负载均衡，扩缩容，流量治理等
- 可观测性：日志采集，分析；监控打点，异常报警，链路追踪等
- 安全：身份验证，认知授权，传输加密等
微服务架构原理及特征
概念
一组具有相同逻辑的运行实体（比如完成某项特定功能的一组）即为服务，在一个服务中，每个运行实体即为一个实例。
有状态/无状态指的是服务实例是否存粹了可持久化数据
通信
对于单体服务而言，不同功能模块的通信就是单纯的函数调用；
对于微服务而言，却是通过grpc，thrift，http等进行网络传输；
服务注册
微服务相互调用的时候，如果靠DNS会存在很多问题：延时，负载均衡，不支持探活，域名端口；
于是框架下新增一个统一的服务注册发现中心（etcd等），用来存储服务名到服务实例的映射，这样问题就得到了解决；
流量特征
- 统一的网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布（deployment）：让服务升级运行新的代码的过程
处理难点
- 服务不可用：调用的服务进入维护或者停用
- 服务抖动：实例增删造成抖动
- 服务回滚：类似事务回滚
蓝绿发布
在蓝绿部署时，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。 例如发布前，在蓝色的系统上进行测试，测试完成后切换为蓝色系统，同时观察蓝色系统的运行状态，如果运行出现问题可以及时切回绿色系统。
灰度发布（金丝雀发布）
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
在灰度发布开始后，会先启动一个新版本应用，但是并不会直接将流量切换过来。测试成功后，将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，这就像金丝雀一样进行测试，收集各种运行时数据，如果此时对新旧版本做各种数据对比。当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
流量治理
微服务框架下，可以有多个维度来对每个路由路径的流量进行控制
负载均衡
负责分配请求在每个下游实例上的分布
稳定性治理
- 限流
- 熔断
- 过载保护
- 降级
个人总结
其实对于微服务我是先实践再补理论的，项目从单体走向微服务中边拆边学，现在再补充一些体系结构挺好。
