微服务的发展

近几年来，互联网企业基本上都是在使用微服务进行服务开发，如果你要找后端工作，无论岗位要求怎么筛选，到最后熟练使用微服务也是一项必备技能。

关于微服务，它的前世今生，它的内容分块，它的衍生治理，它的未来发展，我这里想做一下总结。

架构演变

这里先放一张简单的图示，表示网站架构发展到微服务的演变过程。

单体结构

单体结构，就是所有代码都放在一起，没有任何模块区分，没有前后端分离，一个大项目承担了网站所有功能

20多年前，或者更久之前，我们不管做什么都是一个单体结构，因为思想上够简单，简简单单一把梭，所有人都基于单体结构开发。

单体结构优点：

• 结构简单，所有功能逻辑都在一个项目中
• 部署方便（一个PHP项目/War包)
• 单节点，运维成本低

但是缺点也很明显，都是因为过度的耦合导致。

单体结构缺点：

• 耦合紧密，牵一发而动全身，开发、维护成本高
• 新增业务困难，迭代速度越来越慢
• 无法按需伸缩，通过集群的方式水平扩展，无法针对特定业务按需伸缩

既然有问题，那就要解决。解决单体的最好办法，就是模块化，去耦合。

垂直结构

垂直结构的应用，将不同的功能拆分成各个子系统，开发任务以及入站流量都分派到不同的子系统中

垂直结构优点：

• 系统拆分实现了流量分担，解决了一些并发问题
• 可以根据不同模块进行优化
• 子系统可以按需伸缩

但还有一些问题需要解决：

• 子系统之间存在数据冗余和功能冗余 （比如上面图片中，都有用户服务）
• 按需伸缩力度不够，子系统中的具体业务无法按需伸缩（比如用户服务）

SOA

SOA，即面向服务架构，提倡将系统拆分成不同的子服务（组件）。服务间多以WebService/RPC等方式进行通信，采用ESB(企业服务总线)

SOA架构优点众多：

• 服务化思想，代码复用性提高
• 单服务开发维护复杂度降低
• 可以根据单个业务服务进行水平扩展

但是SOA时代，协议泛滥，为了做统一管理，往往中间要使用企业服务总线(ESB)来统一调度，过度依赖ESB。

SOA架构缺点：

• 集中管理，过度依赖企业服务总线
• 通讯方式偏重(RPC，MQ，SOAP)
• 适配新技术困难
• 运维配套技术设施不先进（手工运维，扩展还是麻烦）

注意，现在大部分人眼中的SOA就是微服务，上面说的这些也就都没有了，我这里只是按照时间发展梳理了下早期SOA的情况，SOA的末期以及微服务的发展基本上是交替的，这两者的区别，估计很多人也说不出来个所以然来

微服务

随着SOA的不断发展，现在逐渐演变为微服务架构。微服务架构将所有的功能规划成一个自成体系的子服务，微服务和微服务之间互相通讯，大多是轻量级的HTTP。

微服务优点：

• 高度解耦，职能单一化
• 单独部署，进程隔离
• 运维更智能，四处分布的微服务，通过注册中心自发现
• 轻量级通讯(HTTP/REST)，扩展方便，新技术适配更简单

微服务缺点：

• 技术门槛变高
• 运维/服务治理更麻烦了

微服务治理：新技术架构带来的新挑战

随着微服务的普及，以及互联网流量日益激增，带来了不少问题。

这里我用问答的形式来阐述问题以及对应治理采用的方法。

问: 服务那么多，我怎么知道我该调用哪个服务，服务出问题了怎么剔除？
答: 注册中心: 服务注册/发现/剔除

问: 项目以及环境实在太多了，有没有一个管理配置的地方？
答: 配置中心

问: 微服务之间如何相互通讯呢？
答: 通讯框架: RPC/HTTP

问: 是否可以对流量进行管控，防止破坏系统？
答: 服务容错机制

问: 一旦某个系统出现问题，如何高效排错？如何监控全部的服务提早发现问题？
答: 服务监控: 度量、日志、链路追踪

问: 是否可以集中治理入口流量，并非只是传统路由转发？
答: API网关 （安全/统计/监控/追踪/服务容错/智能路由/负载均衡等）

基于Java技术栈，有一系列的治理方法。

支持CP的注册中心都可以做配置中心，因为可以做到分布式一致性，无非就是加一些可以被各个Client统一识别同步的配置文件。 CAP原理参看后面的内容。

注册中心

注册中心：负责服务注册、发现、删除等管理。

其实，我们的手机通讯录，就是一个小型的注册中心。 我们给人打电话，先去通讯录中找到对方的标记（他的名字），然后点击他的名字，通讯录自动就弹出他的电话号码，这就类似一个标签对应的具体服务器的地址。然后我们打出电话，就是微服务里面的服务调用。

这么一想，DNS也是一个注册中心，不是吗？

思考一下，直接用DNS做微服务的注册中心不行吗？回答：更新后起效太慢，无法达到现有微服务快速变化迭代的需求。

注册中心，因为是需要管理分布式系统，就会满足分布式系统的CAP定理。
即分布式系统中，以下三个特性不可能同时满足：

Consistency: 一致性
Availability: 可用性
Partition Tolerance: 分区容错性，系统不Down掉

P基本上是要固定的，所以一般是权衡AP还是CP

2000年加州大学的计算机科学家 Eric Brewer 提出CAP理论

P: 不管分布式系统里面的分区之间是否断网、断开，数据是否一致，都需要对外提供服务。其实CAP定理前提就是固定P，没有CA的说法只有AP,CP。假设CA，没有P，那么P出问题也就是分区断开的时候，为了保证C，很显然就需要禁止写入了，这就影响A了，所以前提不成立。所以P是必须固定的。

AP： 为了高性能高吞吐
CP: 为了强一致性，（金融业）

AP代表: Eureka
CP代表: Zookeeper

配置中心

如果一个系统没有配置中心，就比如Spring-Boot项目，需要针对每个环境（生产环境、测试环境、验收环境、预生产环境等）都有一份配置。不仅繁琐笨重，
还容易搞混淆，莫名其妙搞错。

理论上，一个比较可靠的能存储数据的分布式系统，就可以当做一个配置中心。
比如Zookeeper，比如Etcd，但是，仅仅只是能用还不行，我们还需要好用。就比如基于Git的SpringCloud Config就不太好用。

这里比较推荐美团的Apollo配置中心，阿里的Nacos也不错，不过配置管理方面还差了Apollo不少。

服务调用

在SOA时代，各种RPC框架横行，服务之间都是采用RPC进行通讯，当然还有其他协议，不够统一。微服务时代一般是采用HTTP的轻量级通讯，使用成熟轻量的通讯框架，可以更好的在不同的技术栈中平滑过度(不论你是Java还是GO，是PHP还是NodeJs，HTTP协议都在那，无需特别编码，方便集成使用）。

说道服务调用，说到RPC，这里就不得不提一下鼎鼎大名的 Dubbo 了。

Dubbo诞生于SOA时代，期初只是一个RPC框架，在众多的RPC框架中格外耀眼。后来被人寄予厚望，做了很多其他服务治理的工作。本来好好地一个RPC框架，硬是被大家推到了一个微服务治理的集大成者，其3.0版本直接对标云原生。

早期Dubbo并没有那么多治理功能，下图是网上的一个对比图

当然现在Dubbo基本上是一个完备的服务治理框架了。

Dubbo的故事还没结束，有兴趣的大家可以去其官网看看现在的进度。

服务容错

大多数服务在调用链的中间，既有上游，又有下游。如果任何一方出现问题，都会影响到当前服务，那么如何做到上下游的服务出现问题都不影响当前服务，就是服务容错机制需要做的事情。

防止一个服务出错导致上下游的服务雪崩，常用技术手段如下：

• 超时重试
• 熔断
• 限流
• 降级

服务监控

我们需要知道服务的质量，就需要有各种监控工具。

包括以下三类：

• 度量(Metrics)
• 日志(Logging)
• 追踪(Tracing)

三者之间有自己的特点，但很多功能类似，都有部分重叠。

度量：关心线上服务以及周边的一切指标,包括：运行环境监控和应用服务监控。

传统运维时期，这个是我们主要关注的点，只要机器和应用运行还算正常，就万事大吉。

各种监控工具很多，但是现在业界最受欢迎的监控度量工具，主要是 Prometheus + Grafana，经典的有zabbix

日志：服务运行过程中的行为记录，这个大家比较熟悉了，现在的主流还是ELK（ElasticSearch/Logstash/Kibana)或者EFK(ElastiSearch/FileBeat/Kibana) 。其他的还有Loki（更轻量级）和基于ClickHouse自研工具等等。

链路追踪：微服务的调用是复杂的，某次调用中到底是哪个地方出现问题了，需要搞明白，这就需要有一个追踪手段。现在还有个APM(Application Performance Management)的概念，也大概是说全链路监控追踪，差不多一个意思。

下图是云原生环境(Istio内置）最火的Jaeger的链路追踪截图。

常见的其他链路追踪的还有zipkin, skywalking等

API Gateway (可编程网关)

传统网关的概念很早就有了，就是网络的一道关隘，所有外部流量要进入内部系统，都需要先通过网关。传统网关主要是做路由转发、负载均衡、以及部分WAF(网络应用防火墙)功能。

API Gateway的意思就是在传统网关之上，加入可编程能力，将更多的逻辑接入到网关层。
比如前面服务容错需要用到的限流、熔断等，比如身份验证、鉴权，再比如各种协议适配（中转）、再比如做统一日志。

API Gateway可以做的事情越来越多，或者说大家将越来越多的功能赋予它，将它打造的越来越重要。

微服务的下一步：云原生

云原生(Cloud Native)的概念在最近几年被炒得火热，貌似是个互联网公司都在做云原生，可是云原生到底是个什么，怎么定义的？可能很多人还不明白。这里我拿一下现在云原生最具权威的CNCF(Cloud Native Computing Foundation)官方的定义(官方地址)：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

上面的定义中，提到了下面几个基础技术：

• 容器技术
• 服务网格
• 微服务
• 不可变基础设施
• 声明式API

大多数人对于云原生的概念一般是：微服务 + DevOps + 容器化 + 持续交付。 这其实就是一个比较狭隘的容器化生态。

云原生这里特别强调一个原生(Native)，它提出来的不可变基础设施和声明式API，就是对这个的典型阐述。不可变基础设施的意思，就有点类似于一些编程语言里面的不可变值（比如var和val)，和不可变值防止了针对该值的意外修改带来的不可控因素一样，不可变基础设施，就是无论你怎么操作、怎么部署，永远不会影响我的基础设施。比如各类公有云的LAAS/PAAS之类，比如Docker的文件分层。外部的修改，永远不会影响内部，只是记录了一份变动日志，仅此而已。这样的好处是，无论发生了什么突发事件，某个恶意修改，永远影响不了其他的基础设施的健康。

声明式API就是一种约定优先配置，在已定义好的框架内，我们声明好应该在哪些地方有哪些配置，而不是直接给出操作命令。

声明式API对应的是传统的命令式API。

命令式：你去做，你去干，你等下拿个某某某。
声明式：这里有个房子，里面有两个房间，主卧和次卧。

基于云原生环境下的微服务，又有了长足的进步，我们可以跳出某个编程语言的技术栈(比如Spring全家桶），和其他技术栈(Golang，NodeJS等)无缝衔接。这时候的服务治理又有了一些新的变化。

再下一步 - Serverless

打从云计算开始，各大公司为了提高资源使用率，帮各个企业降本增效，提供了一个又一个的服务。从LAAS 到PAAS，从PAAS到SAAS，从SAAS到FAAS，各种理念层出不穷，将资源一分再分，让大家更合理的最小成本的使用服务。

Serverless的字面意思，就是无服务器。

无服务器，是说不用服务器了吗？其实不是，他只是一种软件架构，让我们可以彻底和服务器解耦，只在需要提供服务的时候，可伸缩的请求服务器资源，使用完后就释放，这样可以更大可能的节省资源。

在2012年，Serverless就被Iron公司剔除，到了2014年，AWS推出Lambda之后，这个概念就越来越火，各大云厂商都在跟进，比如微软，谷歌，IBM等，推出自己的Serverless产品。

国内在2017年的是时候，阿里云和腾讯云先后推出了自己的Serverless平台，这个时候，其实只是单纯的FAAS(Function As A Service)，服务器资源并非是按需使用，后来才慢慢发展成了现在的模样。

下面贴几张阿里云的Serverless介绍图

总结

企业服务的技术架构是一直在变化中前进的，只有不断尝试新技术，使用新理念、新思想来武装我们，才能更有效率的帮助企业在新的浪潮中寻求更多机会。