【青训营】微服务架构概览

微服务架构概览

架构概览

中间是核心组件，中间通过一个网关处理外部流量，外围有服务配置和治理模块以及链路追踪和监控。

微服务架构的核心要素

微服务架构原理以及特征

基本概念

• 服务Service
  
  一组具有相同逻辑的运行实体
  
• 实例Instance
  
  一个服务中，每一个运行实体就是一个实例

如上图，一个服务的源代码进行编译和部署之后，可以生成多个实例
实例和进程之间没有必然对应关系，一个实例可以对应一个或者多个进程

• 集群
  
  通常指的是服务内部的逻辑划分，一个集群中可以有多个实例
• 有状态/无状态服务
  
  服务的实例是否存储了可持久化的数据

服务之间通信

对于单体服务，不同模块的通信只是简单的函数调用
但是对于微服务，服务之间通信意味着网络传输

那么，在代码层面，如何指定调用一个目标服务的地址？

在前面的简单例子我们是这样写的：

// Service A wants to call B
client := grpc.NewClient("10.23.45.67:8080")

一方面，这样写有硬编码的问题，另一方面，一个服务会对应多个实体，这样写我们只会访问到一个实体，使得负载失去平衡

解决思路就是，新建一个统一的服务注册中心，用于存储服务名到服务实例的映射。这类似于一个哈希表

如果我们发现第三个实例出现问题了，需要下线怎么办呢？管理员只需要去服务注册中心将第三个实例的记录删除。然后过一段时间后，使用第三个实例的其他服务都已经退出了，就可以将第三个实例下线。

如果发现现在的实例数量不足以应对流量，那可以先新建实例，然后再去服务注册中心将对应服务记录添加到哈希表中

服务发布

服务发布就是让一个服务升级运行新的代码的过程。
在线服务是不能按照传统的停机——更换服务——上线的流程的，尤其是分布式和微服务场景，部分的服务维护会导致应用不可用

蓝绿发布

将服务分为两个Cluster，一个为绿集群，一个为蓝集群，如果要升级，则先切断绿集群，将访问请求导向蓝集群，然后重复上述操作升级蓝集群。这种方法简单稳定，但是需要两倍的资源

蓝绿部署最好是在流量低峰期进行部署

灰度发布（金丝雀发布）

金丝雀对瓦斯及其敏感，十八世纪英国矿工在下矿前会携带金丝雀以确认是否有瓦斯，金丝雀发布也是。

一开始只有三个实例，先添加一个金丝雀实例，若没有问题则撤掉一个老旧实例，重复此过程，直到所有实例都完成替换。但是灰度发布对流量的控制需要很精准，而且一旦出错回滚成本十分大