这是我参加「第五届青训营」伴学笔记创作活动的第12天。
微服务框架架构
在微服务架构中本身服务是一等公民的话，那么相应的针对这些服务的各种配置，我们其实是需要一个基础化的一个能力就来支持的。那么这也是服务配置和治理相关的相应的功能。然后链路追踪和监控，微服务架构它本身是一个特别庞大的一个分布式系统。我们需要对上面进行各种问题的定位的话，这需要统一的一个平台层面的能力才能够支撑的。否则我们不可能对每一个服务进行传统的像单体架构那样的直接去看日志之类的那种比较古老的一个开头方法，必须有一个平台级的链路追踪和监控的能力支撑，这是微服务架构的一个整体的概览。
基本概念
- 服务（Service）： 一组具有相同逻辑的运行实体
- 实例（Instance）： 一个服务中，每个运行实体即为一个实例
- 实例与进程的关系： 实例与进程之间没有必然对应关系，一个实例可以对应一个或多个进程（反之不常见）
- 集群（Cluster）： 通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式： 进程、VM、k8s pod......
- 有状态/无状态服务： 服务的实例是否存储了可持久化的数据（例如磁盘文件）
- 服务间通信：
- 对于单体服务，不同模块通信只是简单的函数调用
- 对于微服务，服务间通信意味着网络传输
服务发布方式
- 蓝绿部署：一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统，切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统工作状态，如果出现问题，直接切换回绿色系统。
- 金丝雀发布：17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
