微服务基础知识

1 微服务基础知识

软件架构的发展经历了从单体结构、垂直架构、SOA架构到微服务架构的过程。

1.1 系统架构的演变

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

1.1.1 单体应用架构

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

图一：

图二：

图三：

特点：

1、所有的功能集成在一个项目工程中。

2、所有的功能打一个war包部署到服务器。

3、应用与数据库分开部署。

4、通过部署应用集群和数据库集群来提高系统的性能。

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

运行的系统就叫做单体架构。

优点：

所有的功能集成在一个项目工程中

项目架构简单，前期开发成本低，周期短，小型项目的首选。

缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

技术栈受限。

代码耦合度高，后期维护困难

无法针对不同模块进行针对性优化

无法水平扩展

单点容错率低，并发能力差

1.1.2 垂直应用架构

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

图一：

图二：

图三：

特点：

1、以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。

2、项目与项目之间的存在数据冗余，耦合性较大，比如上图中三个项目都存在客户信息。

3、项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点：

项目架构简单，前期开发成本低，周期短，小型项目的首选。

通过垂直拆分，原来的单体项目不至于无限扩大

不同的项目可采用不同的技术。

系统拆分实现了流量分担，解决了并发问题。

可以针对不同模块进行优化。

方便水平扩展，负载均衡，容错率提高。

缺点：

全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

系统间相互独立，会有很多重复开发工作，影响开发效率

1.1.3 分布式服务

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

优点：

将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护

1.1.4 分布式SOA架构

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

1.1.4.1 什么是SOA

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

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

把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

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

1.1.4.2 SOA架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定

的服务中心，使前端应用能更快速的响应多变的市场需求。

SOA结构图1：

图二：

图3：

特点：

1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。

2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。

3、ESB企业服务总线作为项目与服务之间通信的桥梁。

优点：

抽取公共的功能为服务,提高开发效率

对不同的服务进行集群化部署解决系统压力

基于ESB/DUBBO减少系统耦合

将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

可以针对不同服务的特点制定集群及优化方案。

采用ESB减少系统中的接口耦合。

缺点：

抽取服务的粒度较大

服务提供方与调用方接口耦合度较高

系统与服务的界限模糊，不利于开发及维护。

虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

抽取的服务的粒度过大，系统与服务之间耦合性高。

1.1.5 微服务架构

图1：

图2：

特点：

1、将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。

2、微服务遵循单一原则。

3、微服务之间采用RESTful等轻量协议传输。

优点：

通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成

本也将大幅度下降微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

服务拆分粒度更细，有利于资源重复利用，提高开发效率。

可以更加精准的制定每个服务的优化方案，提高系统可维护性。

微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量。

适用于互联网时代，产品迭代周期更短。

缺点：

微服务过多，服务治理成本高，不利于系统维护。

分布式系统开发的技术成本高（容错、分布式事务等）。

微服务过多，服务治理成本高，不利于系统维护。

分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大

1.2 微服务的特点：

单一职责： 微服务中每一个服务都对应唯一的业务能力，做到单一职责

微： 微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。

面向服务： 面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现， 做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。

自治： 自治是说服务间互相独立，互不干扰

团队独立： 每个服务都是一个独立的开发团队，人数不能过多。

技术独立： 因为是面向服务，提供Rest接口，使用什么技术没有别人干涉

前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动端开发不同接口

数据库分离：每个服务都使用自己的数据源部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务的核心就是将传统的单一应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事。

在 IDEA 工具中使用Maven构建的一个个独立的 Module ，也就是使用Spring Boot 开发的一个个小模块就是一个个微服务，将专业的事交给专业的模块来做。比如一个大型项目可能有上百个微服务，将这些微服务集中起来构成一个大的系统，对外暴露服务进行调用与使用。

从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

1.3 SOA与微服务的关系

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

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

这些小应用之间通过服务完成交互和集成。

1.4 服务调用方式 （分布式中的远程调用）

1.4.1. RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？ 常见的远程调用方式有以下2种：

RPC：

远程过程调用，RPC基于Socket，工作在会话层。自定义数据格式，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表.

Http：

http其实是一种网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器 与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的 提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

现在热门的Rest风格，就可以通过http协议来实现。

区别：

RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。 相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么Spring Cloud搭建微服务是不二之选。在我们的项 目中，会选择Spring Cloud套件，因此会使用Http方式来实现服务间调用。

1.5分布式中的CAP原理

现如今，对于多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的

CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

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

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

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

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

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

1.6 常见微服务框架

1.6.1 SpringCloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用

Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家

公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉

了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具

包。

1.6.2 ServiceComb

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

1.6.3 ZeroC ICE

ZeroC IceGrid 是ZeroC公司的杰作，继承了CORBA的血统，是新一代的面向对象的分布式系统中间

件。作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力。

1.7什么是微服务

微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自已的进程中，服务之间采用轻量级的HTTP通信机制 ( 通常是采用HTTP的RESTful API )进行通信。这些服务可以用不同的编程语 言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。