微服务设计（一）—微服务架构基础

一、系统架构的演变

1、技术架构发展历史时间轴

①单机垂直拆分：应用间进行了解耦，系统容错提高了，也解决了独立应用发布的问题，存在单机计算能力瓶颈。

②集群化负载均衡可有效解决单机情况下并发量不足瓶颈。

③服务改造架构

虽然系统经过了垂直拆分，但是拆分之后发现有重复的功能，比如，用户注册、发邮件等等，一旦项目大了，集群部署多了，这些重复的功能无疑会造成资源浪费，所以会把重复功能抽取出来，名字叫”XX服务（Service）”。为了解决服务跟服务如何相互调用，需要一个程序之间的通信协议，所以就有了远程过程调用（RPC），作用就是让服务之间的程序调用变得像本地调用一样的简单。

优点：在垂直架构的基础上解决了业务重用的问题。

④服务治理

随着业务的增大，基础服务越来越多，调用网的关系由最初的几个增加到几十上百，造成了调用链路错综复杂，需要对服务进行治理。服务治理要求：当服务节点数几十上百的时候，需要对服务有动态的感知，引入了注册中心。当服务链路调用很长的时候如何实现链路的监控。单个服务的异常，如何能避免整条链路的异常（雪崩），需要考虑熔断、降级、限流。服务高可用：负载均衡。典型框架比如有：Dubbo，默认采用的是Zookeeper作为注册中心。

⑤微服务时代

微服务是在2012年提出的概念，微服务的希望的重点是一个服务只负责一 个独立的功能。 拆分原则，任何一个需求不会因为发布或者维护而影响到不相关的服务， 一切可以做到独立部署运维。 比如传统的”用户中心”服务，对于微服务来说，需要根据业务再次拆分，可 能需要拆分成”买家服务”、”卖家服务”、”商家服务”等。 典型代表：Spring Cloud，相对于传统分布式架构，SpringCloud使用的是 HTTP作为RPC远程调用，配合上注册中心Eureka和API网关Zuul，可以做到细 分内部服务的同时又可以对外暴露统一的接口，让外部对系统内部架构无感， 此外Spring Cloud的config组件还可以把配置统一管理。

Spring Cloud微服务架构存在的不足： Spring Cloud属于侵入式框架，在项目中需要添加spring cloud maven 依赖，加上spring cloud组件注解，写配置，打成jar的时候还必须要把非业务的代码也要融合在一起。 微服务中的服务支持不同语言开发，也需要维护不同语言和非业务代码 的成本； 业务代码开发者应该把更多的精力投入到业务熟悉度上，而不应该是非 业务上，Spring Cloud虽然能解决微服务领域的很多问题，但是学习成本还是较大的。 互联网公司产品的版本升级是非常频繁的，为了维护各个版本的兼容 性、权限、流量等，因为Spring Cloud是”代码侵入式的框架”，这时候 版本的升级就注定要让非业务代码一起，一旦出现问题，再加上多语言之间的调用，工程师会非常痛苦。 我们已经感觉到了，服务拆分的越细，只是感觉上轻量级解耦了，但是维护成本却越高了。

⑥服务网格新时期 （Service Mesh）

Service Mesh主要解决的问题就希望开发人员对于业务的聚焦，服务发 现、服务注册、负载均衡等对于开发人员透明，可以更加专注业务逻辑的实 现。 如果将为微服务提供通信服务的这部分逻辑从应用程序进程中抽取出来， 作为一个单独的进程进行部署，并将其作为服务间的通信代理，可以得到如下 图所示的架构：

当服务大量部署时，随着服务部署的Sidecar代理之间的连接形成了一个如下图所示的网格，该网格成为了微服务的通讯基础设施层，承载了微服务之间的所有流量，被称之为Service Mesh（服务网格）。

服务网格中有数量众多的Sidecar代理，如果对每个代理分别进行设置，工作量将非常巨大。为了更方便地对服务网格中的代理进行统一集中控制，在服务网格上增加了控制面组件。

服务网格用来描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性不断的增长，它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务网格通常还有更复杂的运维需求，比如 A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证。

Istio

2017年5月24日，Google, IBM 和 Lyft 共同发布 Istio 的第一个公开版本(0.1)。Istio为一款开源的为微服务提供服务间连接、管理以及安全保障的平台软件，支持运行在Kubernetes、Mesos等容器管理工具，但不限于Kubernetes、Mesos，其底层依赖于Envoy。Istio提供一种简单的方法实现服务间的负载均衡、服务间认证、监控等功能，而且无需应用层代码调整。其控制平面由Pilot、Citadel 和 Galley组成，数据平面由Envoy实现，通常情况下，数据平面代理Envoy以sidecar模式部署，使得所有服务间的网络通信均由Envoy实现，而Istio的控制平面则负责服务间流量管理、安全通信策略等功能。

istio 架构

实际上Istio 就是 Service Mesh 架构的一种实现，服务之间的通信（比如这里的 Service A 访问 Service B）会通过代理（默认是 Envoy）来进行。而且中间的网络协议支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以说覆盖了主流的通信协议。代理这一层，称之为数据平面。控制平面做了进一步的细分，分成了 Pilot、Citadel 和 Galley，它们的各自功能如下：Pilot：为 Envoy 提供了服务发现，流量管理和智能路由（AB 测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。Citadel：为服务之间提供认证和证书管理，可以让服务自动升级成 TLS协议。Galley：Galley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节隔离开来。数据平面会和控制平面通信，一方面可以获取需要的服务之间的信息，另一方面也可以汇报服务调用的 Metrics 数据。

为什么使用 Istio ？

通过负载均衡、服务间的身份验证、监控等方法，Istio 可以轻松地创建一个已经部署了服务的网络，而服务的代码只需很少更改甚至无需更改。通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理Istio，这包括：为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。可插拔的策略层和配置 API，支持访问控制、速率限制和配额。集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。Istio 为可扩展性而设计，可以满足不同的部署需求。

二、架构特点分析

1 单体应用架构（ALL IN ONE）

单体应用架构应用大部分都是一个WAR包或者JAR包，包含前端页面，后端三层架构（web层，service层，dao层），即将所有的功能模块打包到一起并放在一个web容器中（如tomcat）运行。

优点： 所有功能集成在一个项目工程中，项目架构简单，前期开发成本低，要快速增加新功能或部署发布都比较简单，小型项目的首选，项目初期是一种比较好的方案。

缺点： 对于大型项目不易扩展。 系统性能受限，系统性能扩展只能通过扩展集群节点的方式，成本高，技术栈受限，有瓶颈。

2 垂直应用架构

随着用户量越来越多，系统的压力也随之增长。当并发访问量提高到一定程度，单一应用通过增加机器提高性能的方式瓶颈越来越明显，在系统不能支撑当前的用户量后，需要将项目按照不同的业务来做拆分，拆分为多个子系统，系统之间通过Webservice或者HTTP接口来进行交互，系统不再那么臃肿了。当其中某一个模块使用的频率比较高，就对这个模块进行扩展，即多部署几个节点。再加一个Nginx用于负载均衡，刚开始还没什么大问题，当子系统越来越多的时候，每个子系统前面都要加一层负载，对运维人员来说工作量就增加了，因为要维护的也增多了。

优点： 通过垂直拆分，可在一定程度上突破原来单体应用的并发访问瓶颈，不同的子项目可采用不同的技术，技术栈相对丰富。

缺点：①随着用户量的增加及系统性能的提升，需要拆分的子项目越来越多，运维成本大幅度提升。

②按照业务拆分的子系统，各个子系统之间存在重合的服务，如用户注册、邮件发送等，重复的功能会造成资源浪费，需要进一步抽取公共功能作为独立服务。

3 分布式SOA架构

3.1 SOA

SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进 程中。 站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 即SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

优点： 抽取公共的功能为服务,提高开发效率对不同的服务进行集群化部署解决系统压力 基于ESB/DUBBO减少系统耦合。

缺点： 抽取服务的粒度较大 服务提供方与调用方接口耦合度较高。

3.2 微服务架构

优点： 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成 本也将大幅度下降 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

缺点： 微服务过多，服务治理成本高，不利于系统维护。 分布式系统开发的技术成本高（容错、分布式事务等）。

3.3 SOA与微服务的关系

SOA（ Service Oriented Architecture ）”面向服务的架构”：是一种设计方法，其中包含多个服 务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

微服务架构：其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是”业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。

4 分布式核心知识

1） 分布式中的远程调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

（1）RESTful接口 REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架 构。

资源（Resources）

所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图 片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它， 每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地 址或独一无二的识别符。REST的名称”表现层状态转化”中，省略了主语。

“表现层”其实指的是”资 源”（Resources）的”表现层”。

表现层（Representation） “资源”是一种信息实体，它可以有多种外在表现形式。我们把”资源”具体呈现出来的形式，叫做它的”表 现层”（Representation）。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格 式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。URI只代表资源 的实体，不代表它的形式。严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示 格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。

状态转化（State Transfer） 访问一个网站，就代表了客户端和服务器的一个互动过程。

在这个过程中，势必涉及到数据和状态的变 化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因 此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词： GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源 （也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

综合上面的解释，我们总结一下什么是RESTful架构： 每一个URI代表一种资源； 客户端和服务器之间，传递这种资源的某种表现层； 客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。

（2）RPC协议

RPC（Remote Procedure Call ） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者 UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么 位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

（3）区别与联系

1、HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如 开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持 的几个协议都包含RESTful。

2、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样 调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2） 分布式中的CAP原理

现如今，对于多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的 起点。 CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的 CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

Consistency（一致性）：数据一致更新，所有数据的变化都是同步的。

Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求

Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。

通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布 式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统中，我们的系统最当关注的就是A（可用性）P（容忍性），通过补偿的机制寻求数据的一致性。

感谢阅读，借鉴了不少大佬资料，如需转载，请注明出处，谢谢！https://www.cnblogs.com/huyangshu-fs/p/12865955.html

Original: https://www.cnblogs.com/huyangshu-fs/p/12865955.html
Author: ys-fullStack
Title: 微服务设计（一）—微服务架构基础