这是我参与「第五届青训营」伴学笔记创作活动的第10天。 本文参考课程内容和网络资料的基础上，结合了自己的理解来讲述微服务架构的架构层次、微服务的原理、微服务的服务注册与发现。下一篇文章讲解核心服务治理详细内容和服务治理实践。
一 微服务架构介绍
系统架构的演进历史
-
单体架构
- 全部模块代码设计在一个项目进程里
-
垂直应用架构
- 按照业务线垂直划分，如将整个项目划分为电商系统，后台系统，广告系统等。
-
分布式架构
-
从原来业务线划分的各个系统中，抽出与业务无关的公共模块，公共模块可复用在多个业务系统中。
-
-
-
SOA架构
- 面向服务，在展现层和服务层之间加一个服务注册中心。服务层的服务，在服务注册中心注册。展现成调用服务中心中注册的服务。
-
微服务架构
- 彻底的服务化，各个业务相互独立，各个服务相互独立。
微服务架构的三大核心要素
| 服务治理 | 可观测性 | 安全 |
|---|---|---|
| 服务注册 | 日志采集 | 身份验证 |
| 服务发现 | 日志分析 | 认证授权 |
| 负载均衡 | 监控打点 | 访问令牌 |
| 扩缩容 | 监控大盘 | 审计 |
| 流量治理 | 异常报警 | 传输加密 |
| 稳定性治理 | 链路追踪 | 黑产攻击 |
这三个方面的设计考虑要素构成，微服务架构的三大核心要素，其中我们课程中的主要内容是服务治理。
二 微服务架构原理
微服务架构的基本概念
- 服务 (service)：一组
（多个）具有相同逻辑（相同代码）的运行实体。所以服务一般是指一组服务，里面有多个节点执行同一份代码。 - 实例 (instance）：一个服务中，每个运行实体
（一个节点/一个代码程序）即为一个实例。 - 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程 (反之不常见)
- 集群(cluster)：通常指服务内部的逻辑划分，由任意多个实例组成一个集群，
如集群1为1~n，集群2为n-1~2n。但是一般来说，某一个实例不会加入两个集群。一般会为了更好操作各个集群，而去做逻辑隔离，让集群之间的实例相互隔离。 - 常见的实例承载形式：进程、VM虚拟机、k8s pod、容器.....
- 有状态 / 无状态服务：服务的实例是否存储了可持久化的数据**(例如存在磁盘文件里)**
解析HDFS的微服务架构示例
如图所示，这一个服务架构分成name node的服务和data node的服务。name node的服务里有一个实例/节点，data node的服务里有三个实例/节点（他们的代码逻辑一样，是同一份代码）。name node的服务和data node的服务的代码逻辑不一样，不是同一份代码。
服务调用与通信
如图所示，服务内网之间相互调用采用RPC二进制传输协议（GO语言有grpc协议），其传输的信息大小和编解码效率高。而流量从外网进来的时候采用的是http文本协议，不适合内部传输。
首先流量从外网进入，经过一个负载均衡器。到达网关然后这一部分使用的是HTTP协议。然后网关将转发流量到指定的服务，这一部分采用RPC。
服务注册与发现（重点！！）
DNS方法
如图，DNS服务器把域名b.service.org映射到服务B的三个实例机器的IP地址。服务A请求服务B的时候直接请求该域名+端口号，端口号只能固定同一个。
该方法存在以下缺陷：
- 本地DNS缓存，导致IP地址更新一次要间隔一定时间，服务切换IP地址后有一定滞后性。
- 负载均衡问题。dns极大概率只访问第一个IP。
- 不支持服务实例的探活检查。无法保持连接。
- 域名无法配置端口，且端口号只能固定同一个。
服务注册中心方法
- 如图，我们增加一个服务注册中心，各个服务各自把自己的IP地址和端口都注册在上面。
解决了DNS缓存滞后问题和无法探活问题 - 我们在访问前先使用svc_reg.find（）方法调用服务注册中心寻找服务B的IP地址+端口号
（解决了端口灵活变动问题）。 - 然后再启用net.dial来通过RPC协议随机访问服务的任一IP地址。
这里通过random(n)实现了一个最简单的随机访问n个ip任意一个的负载均衡，解决负载均衡的平衡问题。
另一方面，服务注册中心的健康检测功能可以实现服务实例的下线和上线。解决了服务实例无法使用时自动下线，并且客户端调用时会自动访问有效的服务实例，而不会去访问失效的服务实例。避免了无效流量涌入无效的服务实例这一问题。
新启动一个服务实例时也会上线注册到服务注册中心，客户端获取服务地址时，能及时获取到最新的IP列表。因此我们在微服务中会更多的使用这一个方法来实现服务注册与发现。
