一起聊服务架构的演进过程

开始

服务架构的演进过程是一个老生常谈的话题了，我结合我以前做过的项目，图文并茂的形式和大家一起重温服务架构的演进过程

服务架构演进总览

自从互联网出现在我们的生活中，它就一直服务着我们，为我们提供各种信息；但是随着信息量大爆炸以及我们对信息的不断渴望，传统的互联网架构已经无法满足我们需求，所以我们需要分布式、微服务。但是微服务架构会带来什么问题呢？

没错，就是复杂的运维成本，我们不得不寻找新的运维神器，能够更好的持续集成、部署产品，下面就一一解释下

单体-垂直架构

单体到垂直架构的转变解决了单体服务拓展的问题，后者相当于多个单体架构的平铺，分库、分服务等

分布式-SOA 架构

这个版本是跨时代、革命性的变革，引入了注册中心的概念，为服务之间的访问提供了条件，当下服务之间的通信基本都是依赖注册中心，注册中心有很多，比如 Zookeeper、Eureka、Nacos、Consul 和 Etcd 等等。

微服务-网格架构

微服务在上面基础上进行了更细粒度的区分，但是同时也带来了系统运维的问题，这时候我们引入了 service mesh 和边车等组件，将 sideCar 和服务应用绑定一起，应用部署的时候不需要关注依赖的其他组件，因为部署应用的时候，也会帮你部署一套 sidecar, 比如 db proxy 等

步入正题

这里我想围绕主流的微服务技术，做一些简单分享，主要设计服务治理、服务调用、服务网关和链路监控等

服务治理

服务治理包括服务注册、服务发现、服务熔断、服务降级和服务限流等，下面将结合项目等进行简单分析：

1、服务注册与发现。单体服务拆分为微服务后，如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的服务发现。所以就需要将服务信息存储到某个载体，载体本身即是微服务治理的服务注册中心，而存储到载体的动作即是 服务注册。

服务调用

2、可观测性。微服务由于较单体应用有了更多的部署载体，需要对众多服务间的调用关系、状态有清晰的掌控。可观测性就包括了调用拓扑关系、监控（Metrics）、日志（Logging）、调用追踪（Trace）等。

3、流量管理。由于微服务本身存在不同版本，在版本更迭过程中，需要对微服务间调用进行控制，以完成微服务版本更迭的平滑。这一过程中需要根据流量的特征（访问参数等）、百分比向不同版本服务分发，这也孵化出灰度发布、蓝绿发布、A/B 测试等服务治理的细分主题。

4、安全。不同微服务承载自身独有的业务职责，对于业务敏感的微服务，需要对其他服务的访问进行认证与鉴权，也就是安全问题。

5、控制。对服务治理能力充分建设后，就需要有足够的控制能力，能实时进行服务治理策略向微服务分发。

服务调用

那各个服务之间是怎么通信的？

GRPC 是 Google 开发的一个高性能、通用的开源 RPC 框架；

RPC 指远程过程调用(Remote Procedure Call),它的调用包含传输协议和编码(对象序列)胁议等，允许运行于一台计算机上的程序调用另一台计算机上的子程序，而开发入员无须额外为这个交互作用编程，就像对本地函数进行调用一样方便。

服务调用

服务网关

1. 统一入口

2. 负载均衡

3. 动态路由

4. 熔断

5. 过滤器

API 网关是一个服务器，是系统对外的唯一入口。API 网关封装了系统内部架构，为每个客户端提供一个定制的 API。API 网关方式的核心要点是：所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也提供 REST/HTTP 的访问 API。服务端通过 API 网关注册和管理服务。常见的微服务网关是 Spring Cloud Gateway、Zuul 等。

服务监控

随着微服务等技术等发展，服务链路会越来越长，我们必须要关注服务等鲁棒性，力求服务稳定可靠；所以我们需要一套完整的服务监控方案，简单介绍几个：

美团 CAT

监控整体要求就是快速发现故障、快速定位故障以及辅助进行程序性能优化。为了做到这些，我们对监控系统的有如下的要求：

• 实时处理：信息的价值会随时间锐减，尤其是事故处理过程中。

• 全量数据：最开始的设计目标就是全量采集，全量的好处有很多。

• 高可用：所有应用都倒下了，需要监控还站着，并告诉工程师发生了什么，做到故障还原和问题定位。

• 故障容忍：CAT 本身故障不应该影响业务正常运转，CAT 挂了，应用不该受影响，只是监控能力暂时减弱。

• 高吞吐：要想还原真相，需要全方位地监控和度量，必须要有超强的处理吞吐能力。

• 可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统。

• 不保证可靠：允许消息丢失，这是一个很重要的 trade-off，目前 CAT 服务端可以做到 4 个 9 的可靠性，可靠系统和不可靠性系统的设计差别非常大。

Pinpoint

pinpoint 能做什么，可以服务的调用链路进行追踪并且当服务调用失败率等进行报警。从产品和功能上类似于 spring cloud sleuth + zipkin（或+kafka）实现的微服务链路追踪；

Jaeger

结束

以上纯属抛砖引玉，也算是为后面的服务架构的分享做了一些开篇介绍，希望对大家有一点点帮助，我们后会有期！