微服务架构 | 青训营

系统架构的演变历史

• 单体架构：所有的应用程序和数据运行在同一物理机上，性能最高但debug困难，功能之间相互影响
• 垂直应用架构：将应用程序拆分成不同的多个功能模块
• 分布式架构：将应用不同的模块分布在不同的物理机上，通过网络进行通信
• SOA架构：将应用程序分解成多个自治的服务，通过网络进行通信
• 微服务架构：SOA的演化影视，粒度更小的服务拆解，每个微服务独立部署，可扩展，可使用不同的技术栈，通过轻量级通信协议交互

微服务架构原理与特征

三大要素：

• 服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理
• 可观测性： 日志采集、日志分析、监控、异常警报、链路追踪
• 安全：身份验证、认证授权、访问令牌、审计、加密传输

基础概念

• 服务：一组具有相同逻辑（运行同一份代码）的运行实体
• 实例：一个服务中，每个运行的实体就是一个实例
• 通信：在微服务中，通信即是网络传输

服务注册与发现

服务注册是为了解决微服务架构中如何去调用目标服务的问题。

• 注册中心：用于存储服务名到服务实例的映射，可以记录当前有多少实例在执行某些服务，结合负载均衡算法可以让调用更稳定，安全，均衡
• 服务注册：实例在服务中心注册自己的元数据信息，包括主机ip和端口号、协议、版本号、运行环境等
• 服务发现：客户端服务进程向注册中心查询并获取可用服务列表

实例的下线：先去通知调用服务的实例，某服务的某实例要下线，此时调用服务的实例会停止调用这个要下线的实例，当没有服务去调用这个实例时即可下线这个实例。如果直接下线实例，会导致调用失败从而导致一系列问题。

实例的上线：先开启实例然后进行健康检测来确保服务的可用，通过健康检测后在注册中心进行注册。

服务发布

服务发布：让一个服务升级运行新代码的过程

难点：

• 服务不可用
• 服务抖动
• 服务回滚

解决办法：

• 蓝绿部署，把要发布的服务分为蓝绿两个部分，让其中一种先进行发布，把流量转移给另外一个；发布完并检测完后，同样步骤升级另外一个颜色
• 灰度发布：不暂停原有的实例，先注册新实例来测试新代码的是否可以正常运行，如果可以正常运行则下线一个老实例，逐步替换

流量治理

在微服务中，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路径进行控制

负载均衡

请求均衡的分配在下游实例中，不要让某一实例负载过大也不要让某一实例负载过小，使用组件LB（Load Balance）

稳定性治理

与程序正确性无关的问题，如

• 网络攻击
• 流量突增
• 光纤被挖
• 机器故障
• 机房空调故障
• ......

措施：

• 限流，rate limit组件
• 熔断，curcuit breaker组件
• 过载保护， dynamic overload组件
• 降级， degrade组件