微服务基础知识

一、系统架构的演变

1.1 单体应用架构

Web 应用程序发展的早期，大部分 web 工程（包含前端页面，web 层代码，service 层代码，dao 层代码）是将所有的功能模块，打包到一起并放在一个 web 容器中运行。

比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个 web 容器中运行的系统就叫做单体架构。

优点：

• 所有的功能集成在一个项目工程中
• 项目加够简单，前期开发成本低，周期短，小型项目的首选

缺点：

• 全部功能集成在一个工程中，对于大型项目不宜开发、扩展及维护
• 系统性能扩展只能通过扩展集群节点，成本高、有瓶颈
• 技术栈受限

1.2 垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分成互不相干的几个应用，以提升效率。

优点：

• 项目架构简单，前期开发成本低，周期短，小型项目的首选
• 通过垂直拆分，原来的单体项目不至于无限扩大
• 不同的项目可采用不同的技术

缺点：

• 拆分后各系统之间相对比较独立，无法直接进行相互调用
• 各系统难免存在重叠的业务，这就导致系统与系统之间可能存在重复性的代码
• 系统性能扩展只能通过扩展集群节点，成本高、有瓶颈

1.3 分布式 SOA 架构

1.3.1 什么是 SOA

SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变成通用的业务服务，实现业务逻辑的快速复用。

通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合。

1.3.2 SOA 架构

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

优点：

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

缺点：

• 抽取服务的粒度较大
• 服务提供方与调用方法接口耦合度较高

关于 SOA、SOAP、WebService、REST 等概念的介绍可以看一下这几篇文章：

SOA,SOAP,RPC,以及 RPC协议与 REST 协议之间的关系(搜狗)
RPC是什么，与WebService有什么异同？
SOA，Webservice，SOAP，REST，RPC，RMI，JMS的区别与联系
Webservice soap wsdl区别之个人见解
理解SOAP和WebService

简单说一下，SOA 是一种架构思想，而 SOAP 是基于 SOA 架构思想的一种通信协议，该协议用于规范发送消息的格式，可以将 SOAP 简单理解为 RPC+HTTP+XML。WebService 是一种标准，该标准包括SOAP、WSDL、UDDL，其中soap用来描述传递信息的格式， WSDL 用来描述如何访问具体的接口， uddi用来管理、分发以及查询WebService。从表面上看，WebService就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。Web Service是真正“办事”的那个，提供一种办事接口的统称。

1.4 微服务架构

优点：

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

缺点：

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

1.5 SOA 与微服务的关系

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

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

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理（服务自治）
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队
服务之间的调用技术	RPC远程调用技术	基于HTTP的web请求方式

二、分布式核心知识

2.1 分布式中的远程调用

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

关于序列化可以看下这篇文章：什么是序列化? 如何实现(反)序列化 序列化的应用

2.1.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.1.2 RPC 协议

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

2.1.3 区别与联系

比较项	RESTful	RPC
通讯协议	HTTP	一般使用 TCP
性能	略低	较高
灵活度	高	低
应用	微服务架构	SOA架构

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

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

2.2 分布式中的 CAP 原理

分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

CAP 理论由 Eric Brewer 在 ACM 研讨会上提出，而后 CAP 被奉为分布式领域的重要理论。分布式系统的 CAP 理论，首先把分布式系统中的三个特性进行了如下归纳：

Consistency（一致性）：数据一致性，所有数据的变化都是同步的
Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求
Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。

关于 CAP 理论为什么无法同时满足三个特点，可以看下这篇文章：揭秘分布式CAP理论——为什么不能同时满足三个？

具体原文如下：
如果CA满足看P是否能满足？
如果AP满足看C是否能满足？
如果CP满足看A是否能满足？

1、如果CA满足看P是否能满足？
我们来分析：当C（Consistency）一致性A（Availability）可用性都满足时会发生什么？为了保持数据的一致性，数据在各个节点间同步需要花费时间，同时保证服务可用意味着服务器的数量不能过多，因为过多就会导致数据同步时间过长，而导致超时触发熔断降级机制，这与可用性相悖。但是如果要满足容错的话就必须是多节点，而多节点意味着同步数据同步时间必定过长，这两无法做到同时满足所以就导致了情况1是无法满足。

2、如果AP满足看C能否满足？
我们来分析：当A（Availability）可用性和P（Partition tolerance）分区容错性都满足的情况下会发生什么？服务器多节点部署，导致服务器数量剧增，同时需要保证服务节点可用，这就说明服务节点与节点之间的调用时间无法过长，否则就会导致服务节点不可用。如果在这种情况下，满足C（Consistency）一致性，就会出现服务器因同步数据而导致浪费大量的时间，导致服务器不可用（超过了规定时间范围），所以当AP满足时是无法同时满足C的。

3、如果CP满足看A是否能满足？
我们来分析：当C（Consistency）一致性和P（Partition tolerance）分区容错性都满足时，这个时候的服务器情况是怎么样的？必定是数量多并且为了保证数据同步大量的服务器节点会进入“超长待机”状态，此时如果再让服务满足A（可用性）的话，就会出现大部分的服务节点不可用，线程池被挤爆，然后整个项目宕机。所以情况3是无法满足的。

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

选择	说明
CA	放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择
AP	放弃一致性（这里说的一致性就是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多 NoSQL 系统就是如此
CP	放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

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

三、常见的微服务框架

3.1 SpringCloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家 公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉 了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

3.2 ServiceComb

Apache ServiceComb 是业界第一个Apache微服务顶级项目， 是一个开源微服务解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站 式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

3.3 ZeroC ICE

ZeroC IceGrid 是ZeroC公司的杰作，继承了CORBA的血统，是新一代的面向对象的分布式系统中间 件。作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力。