1、微服务架构的演变

1.1、单体应用架构–单数据库多应用服务架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后打包部署到一台tomcat服务器上。但是如果用户多了，那就加服务器数目形成负载均衡即可

如上，如果我们需要多台服务器响应更多的用户，同时也要保证数据的一致性。根据数据库的范式理论，数据的冗余性越低，数据的一致性就越高。因此我们的第一步方案可以剥离为多个应用服务器处理用户的请求，一台数据库服务器来集中处理数据的读写，这样就能够达到分摊服务器压力的同时也能保证数据的正确。

不过在应用服务器的入口，我们需要增加一个负载均衡服务器，来分配不同的用户请求到特定的应用服务器上。这有点类似于餐厅的排队机，对用户分流。负载均衡服务器可以是普通PC服务器上配置Nginx一类的软件，也可以是F5这类专用的硬件负载均衡设备。

单体应用架构优点：

• 项目架构简单，小型项目的话， 开发成本低
• 项目部署在一个节点上， 维护方便

单体应用架构缺点：

• 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
• 项目模块之间紧密耦合，单点容错率低
• 无法针对不同模块进行针对性优化和水平扩展
• 容错不好，如果其中一个模块出现问题，可能导致整个项目崩掉。

1.2、垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加服务器节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小。那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了， 垂直应用就应运而生了.

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成:

• 电商系统(用户管理 商品管理 订单管理)
• 后台系统(用户管理 订单管理 客户管理)
• CMS系统(广告管理 营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。然后将三个模块系统，部署到三台服务器上，这样各自应用不会互相干扰，形成分流

优点：

• 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展
• 一个系统的问题不会影响到其他系统，提高容错率

缺点：

• 系统之间相互独立， 无法进行相互调用。
• 系统之间相互独立， 会有重复的开发任务
• 比如后台管理系统要看到电商系统的数据，那么必然调用电商系统的数据内容。这个架构并没有根本上解决高并发的问题。只是将原来的项目，一刀切为3份而已。系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

1.3、分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

抽取公共的功能为服务层，提高代码复用性

缺点：

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

1.4、SOA架构—阿里dubbo

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service OrientedArchitecture，面向服务的架构)是关键。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

优点:

• 使用注册中心解决了服务间调用关系的自动调节
• 我们将这三个系统，拆分成了很多个服务，整个系统分为展示层（消费者）、服务层（提供者）。这样将一个服务单独部署在一个服务器或者集群，然后通过注册中心，消费者调用提供者，展示层通常就是我们说的controller层，服务层就是service

缺点:

• 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
• 服务之间的依赖与调用关系复杂，测试部署的困难比较大。

1.5、微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。在微服务架构下，我们将一个大的项目拆分为一个个小的可以独立部署的微服务，微服务拆分粒度更小，每个服务都对应唯一的业务能力，每个微服务都有自己的数据库。

优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
• 微服务之间可以采用REST和RPC协议进行通信

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务、数据的一致性问题等）

2、什么是微服务

2.1、微服务介绍

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.——James Lewis and Martin Fowler (2014)

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

在微服务架构中，每个服务运行在其独立的进程中，服务与服务之间通信时，通常是通过轻量级的通信机制，实现彼此间的互通互联、互相协作。所谓轻量级通信机制，通常是指与语言无关、与平台无关的这类协议【通常是基于HTTP协议的RESTful API】。通过轻量级通信机制，使服务与服务之间的协作变得简单、标准化。

每个服务都围绕着本业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言，工具对其进行构建。

• 微服务是一种架构风格
• 一个应用拆分为一组小型服务，每个微服务可以对外暴露业务接口，供其他微服务调用
• 每个服务运行在自己的进程内，也就是可独立部署和升级，每个服务都是一个可以独立运行的项目，每个微服务有自己的数据库
• 服务之间使用轻量级HTTP交互
• 服务围绕业务功能拆分
• 可以由全自动部署机制独立部署
• 去中心化，服务自治。服务可以使用不同的语言、不同的存储技术。

一旦采用微服务系统架构，就势必会遇到这样几个问题:

• 这么多小服务，如何管理他们? (服务治理注册中心[服务注册发现剔除])
• 这么多小服务，他们之间如何通讯? (restful rpc)
• 这么多小服务，客户端怎么访问他们? (网关)
• 这么多小服务, 一旦出现问题了，应该如何自处理? (容错)
• 这么多小服务，一旦出现问题了，应该如何排错? (链路追踪)

基于分布式的微服务架构-落地维度

对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。满足哪些维度？支撑起这些维度的具体技术？

2.2、微服务架构的常见概念

服务治理

服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。

• 服务注册：服务实例将自身服务信息注册到注册中心。
• 服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
• 服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

服务调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

• (Representational State Transfer)这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议
• RPC (Remote Promote Call)：一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

服务网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求， 如果让客户端直接与各个微服务通信可能出现:

• 客户端需要调用不同的url地址，增加难度，在一定的场景下，存在跨域请求的问题
• 每个微服务都需要进行单独的身份认证，针对这些问题，API网关顺势而生。

API网关直面意思是将所有API调用统一接入到API网关层， 由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、 容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

服务容错

在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是:

• 不被外界环境影响
• 不被上游请求压垮
• 不被下游响应拖垮

链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪

2.3、微服务架构的常见解决方案

ServiceComb

Apache ServiceComb,前身是华为云的微服务引擎CSE (Cloud Service Engine)云服务，是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。

Dubbo

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 [1]Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

三大部件

• Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制.
• RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能
• Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

springCloud

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

• 服务调用
• 服务降级
• 服务注册与发现
• 服务熔断
• 负载均衡
• 服务消息队列
• 服务网关
• 配置中心管理
• 自动化构建部署
• 服务监控
• 全链路追踪
• 服务定时任务
• 调度操作

SpringCloud Alibaba

Spring Cloud Alibaba致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过Spring Cloud编程模型轻松使用这些组件来开发分布式应用服务。依托Spring Cloud Alibaba,您只需要添加一些注解和少量配置,就可以将Spring Cloud应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

微服务技术对比

感谢阅读，点赞收藏+关注！更多的java课程学习路线,笔记,面试等架构资料，想要学习的同学可以私信我（资料）即可免费获取！