微服务架构概览
架构概览
中间是核心组件，中间通过一个网关处理外部流量，外围有服务配置和治理模块以及链路追踪和监控。
微服务架构的核心要素
微服务架构原理以及特征
基本概念
- 服务Service
一组具有相同逻辑的运行实体 - 实例Instance
一个服务中，每一个运行实体就是一个实例
如上图，一个服务的源代码进行编译和部署之后，可以生成多个实例
实例和进程之间没有必然对应关系，一个实例可以对应一个或者多个进程
- 集群
通常指的是服务内部的逻辑划分，一个集群中可以有多个实例 - 有状态/无状态服务
服务的实例是否存储了可持久化的数据
服务之间通信
对于单体服务，不同模块的通信只是简单的函数调用
但是对于微服务，服务之间通信意味着网络传输
那么，在代码层面，如何指定调用一个目标服务的地址？
在前面的简单例子我们是这样写的：
// Service A wants to call B
client := grpc.NewClient("10.23.45.67:8080")一方面，这样写有硬编码的问题，另一方面，一个服务会对应多个实体，这样写我们只会访问到一个实体，使得负载失去平衡
解决思路就是，新建一个统一的服务注册中心，用于存储服务名到服务实例的映射。这类似于一个哈希表
如果我们发现第三个实例出现问题了，需要下线怎么办呢？管理员只需要去服务注册中心将第三个实例的记录删除。然后过一段时间后，使用第三个实例的其他服务都已经退出了，就可以将第三个实例下线。
如果发现现在的实例数量不足以应对流量，那可以先新建实例，然后再去服务注册中心将对应服务记录添加到哈希表中
服务发布
服务发布就是让一个服务升级运行新的代码的过程。
在线服务是不能按照传统的停机——更换服务——上线的流程的，尤其是分布式和微服务场景，部分的服务维护会导致应用不可用
蓝绿发布
将服务分为两个Cluster，一个为绿集群，一个为蓝集群，如果要升级，则先切断绿集群，将访问请求导向蓝集群，然后重复上述操作升级蓝集群。这种方法简单稳定，但是需要两倍的资源
蓝绿部署最好是在流量低峰期进行部署
灰度发布（金丝雀发布）
金丝雀对瓦斯及其敏感，十八世纪英国矿工在下矿前会携带金丝雀以确认是否有瓦斯，金丝雀发布也是。
一开始只有三个实例，先添加一个金丝雀实例，若没有问题则撤掉一个老旧实例，重复此过程，直到所有实例都完成替换。但是灰度发布对流量的控制需要很精准，而且一旦出错回滚成本十分大
