这是我参与「第三届青训营 -后端场」笔记创作活动的第2篇笔记，今天讲一下系统架构设计中的微服务。

微服务架构

在架构演变之路（一）中，根据发展顺序介绍了几种常见的服务架构和其特点，服务架构发展至今，微服务俨然成为主流，那么本文将就微服务展开介绍，漫谈微服务。

基本概念

由于服务需要经常更新，升级；因此需要统一的服务注册中心管理服务的注册和发现，尤其是对于服务的地址和端口信息的管理。服务的注册和发现主要依靠注册中心，注册中心实时维护服务的真实地址和名称之间的对应关系，对进来的请求进行转发使其能够到达指定的下游服务。

需要注意的是，为了保证平滑的使用使用体验，注册中心需要对服务的上下线进行特殊维护，以保证不会因为下游服务的动态变更导致上游业务故障。

总结下来，微服务的流量特征有以下几点

由于服务发布要面临服务不可用、服务抖动、服务回滚等问题，因此必须充分做好测试和备份，及时发现和处理问题。常见的服务发布方案主要有以下：

蓝绿部署：
- 蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
- 特点
  - 蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。
  - 两套系统没有耦合的时候才能百分百保证不干扰
  - 冗余
滚动发布：
- 一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
- 特点
  - 这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的20%进行升级。
  - 回滚困难
灰度发布：
- 灰度发布, 也叫金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

微服务框架支持对流量进行精细化的调度，基于地区、集群、实例等因素对端到端的流量路由路径进行控制。同时基于流量治理原则也可以很方便的加入负载均衡策略。

微服务对我们的思考，更多的是思维上的转变。对于微服务架构：技术上不是问题，意识比工具重要。