微服务浅谈&服务治理的演变过程

这两天对互联网的架构演变进行了简单了解，并对微服务的出现很感兴趣，因此对相关知识进行了简单的整理与总结。

本篇文章先简单介绍了互联网架构的演变，进而介绍了服务化，最后介绍了微服务及最新的服务网格（Service Mesh）。
---------------------

互联网架构演变

一体架构

在计算机软件发展早期，通常桌面软件都是采用这种架构，无论是界面仍是业务处理仍是数据处理都放到一个包中。这种其实谈不上架构，但也能够说是很好的架构，由于它足够简单。

mvc架构

但随着浏览器的出现便产生了web应用，web应用的特色是界面部分是显示在浏览器中，服务处理是在服务容器中的，页面显示通常用css+js+html技术来处理，然后端能够用java、php等语言，这就产生了先后端分离。对于web系统，一体架构难以知足先后端分离的开发需求，于是便产生了MVC架构。

 

 

MVC才算的上真正意义上的架构，由于它除了解决了先后端分离问题，还引入了一种全新的开发模式，用一种业务逻辑、数据、界面显示分离的方法组织代码，使得整个应用层次更加分明，并且各个层次之间不但减低了耦合性，还提升了各个层次的可重用性。

但随着应用规模的不断扩大，应用模块不断增长，整个应用也显得愈来愈臃肿，维护起来也更加困难，所以便又产生了多应用架构。

多应用架构

多应用架构很简单，就是把原来的应用按照业务特色拆分红多个应用。好比一个大型电商系统可能包含用户系统、商品系统、订单系统、评价系统等等，咱们能够把他们独立出来造成一个个单独的应用。多应用架构的特色是应用之间各自独立 ，不相互调用。

 

多应用虽然解决了应用臃肿问题，但应用之间相互独立，有些共同的业务或代码没法复用。

分布式架构

对于一个大型的互联网系统，通常会包含多个应用，并且应用之间每每还存在共同的业务，而且应用之间还存在调用关系。除此以外 ，对于大型的互联网系统还有一些其它的挑战，好比如何应对急剧增加的用户，如何管理好研发团队快速迭代产品研发，如何保持产品升级更加稳定等等 。

所以，为了使业务获得很好的复用，模块更加容易拓展和维护，咱们但愿业务与应用分离，某个业务再也不属于一个应用，而是做为一个独立的服务单独进行维护。应用自己再也不是一个臃肿的模块堆积，而是由一个个模块化的服务组件组合而成。

 

服务化

服务化的特色

上面介绍的分布式架构即服务化。咱们再总结一下，服务化主要有以下特色：

• 应用按业务拆分红服务
• 各个服务都可独立部署
• 服务可被多个应用共享
• 服务之间能够通讯

服务化的好处

那么企业采用服务化有哪些好处呢？

• 架构上系统更加清晰
• 核心模块稳定，以服务组件为单位进行升级，避免了频繁发布带来的风险
• 开发管理方便
• 单独团队维护、工做分明，职责清晰
• 业务复用、代码复用
• 很是容易拓展

服务化实现方式

若是要实现服务化的话，最经常使用的方式就是利用RPC框架。由于服务组件通常分布在不一样的服务器上，因此要实现服务化须要解决的第一个问题就是RPC**远程服务调用**。相似于RPC方案有不少，好比：

• Java RMI
• WebService
• Hessian
• Http
• Thrift
• … …

服务化面临的挑战

上面提到要实现服务化首先须要解决远程服务调用问题，除此以外，还有不少其余问题须要解决。

• 服务愈来愈多，配置管理复杂
• 服务间依赖关系复杂
• 服务之间的负载均衡
• 服务的拓展
• 服务监控
• 服务降级
• 服务鉴权
• 服务上线与下线
• 服务文档
• … …

服务治理

上面提到了服务化，其实要想服务化，服务治理是关键。那么有没有好的服务治理方案呢？答案是有的，并且不少人都在用这个框架，他就是-dubbo。dubbo就是一个带有服务治理功能的RPC框架。

 

 

dubbo提供了一套较为完整的服务治理方案，因此企业若是要实现服务化的话，dubbo 是很好的一个选择。这里简单介绍一下dubbo服务治理相关方案。

服务发现注册

服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。

 

 

dubbo注册中心服务注册发现的具体过程：

服务提供者启动，向注册中心注册本身提供的服务
消费者启动，向注册中心订阅本身须要的服务
注册中心返回服务提供者的列表给消费者
消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求

服务监控

 

集群容错

 

负载均衡

• Random Loadbalance
• RoundRobin
• LeastActive
• ConsistentHash

dubbo服务治理优点

• 注册中心只负责注册查找，不负责请求转发，压力小
• 注册中心宕机影响消费者，消费者本地缓存服务地址列表
• 注册中心对等集群，宕掉一台自动切换到另外 一台
• 服务提供者无状态，可动态部署，注册中心负责推送
• 统计无压力，本地内存中累计次数，每分钟发送注册中心
• 消费者调用服务者，自动软负载均衡
• 经过服务中心可追踪依赖关系
• 监控中心为扩容和降级提供依据
• 可启用acl机制进行鉴权
• 与Spring整合，接入简单松耦合
• 多种序列化协议支持

dubbo的不足

• 消费者仍须要依赖配置中心
• 消费者仍须要依赖jar包配置provider
• 提供者文档管理功能缺失
• 无统一入口
• 不支持OAuth2.0
• 内部鉴权不方便管理
• 无外部应用鉴权
• 接口基本裸奔，没法直接对外暴露服务
• IT治理不方便

微服务

如今不少人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。

微服务有两个核心：

• 微：服务的粒度要细，即服务要细化到API
• 服务：提供好服务，要让用户感到好用(要作到这一点很不容易)

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下，每一个任务表明着一个小的业务能力。

微服务架构 ≈ 模块化开发 + 分布式计算

 

 

从上面这幅图看出，微服务特别简单（好的架构就应该简单），咱们把服务再拆分红一个个API，API是一个完整的功能。而后咱们把API扔到一个“云上”，而后用户就能够到“云上”获取全部API的服务，这个“云”保证能提供好的服务。

咱们能够看到，有了微服务以后，服务对用户来讲变得特别简单，并且上面dubbo的不足之处在微服务这里都解决了。使用者再也不须要依赖任何jar包，再也不须要去注册中心查找服务，再也不去作鉴权处理，不用担忧服务挂掉，不用担忧不会使用服务，全部的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。

说到这里，你们就应该大致知道该怎么作微服务了，图中的“云”是关键。下面咱们就慢慢拨开这朵云。

微服务的实现

 

微服务的关键是服务网关，因此，上面提到的“云”就是服务网关。要作微服务，咱们先定义一下微服务须要具有的特色。

常见的微服务组件及概念：

• 服务注册：服务提供方将本身调用地址注册到服务注册中心，让服务调用方可以方便地找到本身。
• 服务发现：服务调用方从服务注册中心找到本身须要调用的服务的地址。
• 负载均衡：服务提供方通常以多实例的形式提供服务，负载均衡功能可以让服务调用方链接到合适的服务节点。而且，节点选择的工做对服务调用方来讲是透明的。
• 服务网关：服务网关是服务调用的惟一入口，能够在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
• 配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差异性，方便程序包的迁移。
• API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将全部微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户可以在统一的界面中使用系统。
• 分布式事务：对于重要的业务，须要经过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
• 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展现出来。在系统出错时，能够方便地找到出错点。
• 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就须要将大部分的工做自动化。如今，能够经过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以咱们两年的实践经验，能够这么说，若是没有合适的支撑平台或工具，就不要使用微服务架构。

微服务架构的优势：

• 下降系统复杂度：每一个服务都比较简单，只关注于一个业务功能。
• 松耦合：微服务架构方式是松耦合的，每一个微服务可由不一样团队独立开发，互不影响。
• 跨语言：只要符合服务 API 契约，开发人员能够自由选择开发技术。这就意味着开发人员能够采用新技术编写或重构服务，因为服务相对较小，因此这并不会对总体应用形成太大影响。
• 独立部署：微服务架构可使每一个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改能够在测试经过后当即部署。因此微服务架构也使得 CI／CD 成为可能。
• Docker 容器：和 Docker 容器结合的更好。
• DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。

微服务架构的缺点：

• 微服务强调了服务大小，但实际上这并无一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这自己就是一个经验工程。有些开发者主张 10-100 行代码就应该创建一个微服务。虽然创建小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
• 微服务的分布式特色带来的复杂性：开发人员须要基于 RPC 或者消息实现微服务之间的调用和通讯，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的至关棘手。
• 分区的数据库体系和分布式事务：更新多个业务实体的业务交易至关广泛，不一样服务可能拥有不一样的数据库。CAP 原理的约束，使得咱们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来讲是一个挑战。
• 测试挑战：传统的单体WEB应用只需测试单一的 REST API 便可，而对微服务进行测试，须要启动它依赖的全部其余服务。这种复杂性不可低估。
• 跨多个服务的更改：好比在传统单体应用中，如有 A、B、C 三个服务须要更改，A 依赖 B，B 依赖 C。咱们只需更改相应的模块，而后一次性部署便可。可是在微服务架构中，咱们须要仔细规划和协调每一个服务的变动部署。咱们须要先更新 C，而后更新 B，最后更新 A。
• 部署复杂：微服务由不一样的大量服务构成。每种服务可能拥有本身的配置、应用实例数量以及基础服务地址。这里就须要不一样的配置、部署、扩展和监控组件。此外，咱们还须要服务发现机制，以便服务能够发现与其通讯的其余服务的地址。所以，成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。
• 总的来讲（问题和挑战）：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

微服务要解决的问题

上面提到了，dubbo还存在一些问题 ，其实dubbo存在的问题 就是 微服务要解决的问题，这里 再总结一下。固然，dubbo和微服务的侧重点不同，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。

• 统一入口
• 安全控制：防刷限流
• 统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
• 协议转换：http、dubbo、Protobuf
• API配置管理
• API上线、下线
• API与服务接口映射
• 监控与报警
• 总体架构的可拓展、高并发、分布式
• 服务容器自动收缩、扩容

实现方案

 

• 负载均衡层：nginx/lvs/F5
• 微服务层

　　　　高性能服务网关;
　　　　统一入口、API配置管理、分流鉴权、服务监控、协议转换;
　　　　API映射、OAuth2.0、API文档管理;
　　　　分布式、可拓展;

• 服务治理层

　　　　成熟的服务治理框架dubbo;
　　　　MQ服务之间解耦;

• 弹性云

　　　　服务docker化;
　　　　基于访问压力的实时集群调度与管理;

弹性云

这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉而且有好的性能，须要很高的运维要求。这里的弹性云即是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。

 

服务网格（Service Mesh）

2017 年末，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译做“服务网格”，做为服务间通讯的基础设施层。

若是用一句话来解释什么是 Service Mesh，能够将它比做是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来讲通常无须关心 TCP/IP 这一层（好比经过 HTTP 协议的 RESTful 应用），一样使用 Service Mesh 也就无须关系服务之间的那些原来是经过应用程序或者其余框架实现的事情，好比 Spring Cloud、OSS，如今只要交给 Service Mesh 就能够了。

Service Mesh 的前因后果：

1. 从最原始的主机之间直接使用网线相连
2. 网络层的出现
3. 集成到应用程序内部的控制流
4. 分解到应用程序外部的控制流
5. 应用程序的中集成服务发现和断路器
6. 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候仍是集成在应用程序内部
7. 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
8. 最后做为微服务的中间层 Service Mesh 出现

Service Mesh 有以下几个特色：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

关于微服务和服务网格的区别，个人一些理解：微服务更像是一个服务之间的生态，专一于服务治理等方面，而服务网格更专一于服务之间的通讯，以及和 DevOps 更好的结合。

---------------------
Reference: 
1，微服务架构初探

2，浅谈服务治理与微服务 

3，什么是Service Mesh（服务网格）