为什么使用微服务？微服务解决了什么问题？

目录

---

Spring Cloud Alibaba专栏目录（点击进入…）

---

---

为什么使用微服务？微服务解决了什么问题？

为什么使用微服务？

微服务：把一个单体项目，拆分为多个微服务，每个微服务可以独立技术选型、独立开发、独立部署、独立运维。并且多个服务相互协调、相互配合；最终完成用户的价值

什么是微服务？

微服务架构（Microservice Architecture）是一种架构概念，指通过将功能分解到各个离散的服务中以实现对解决方案的解耦
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务（一个微服务完成一个任务）。在所有情况下，每个任务代表着一个小的业务能力。相对于大规模的集群，微服务带来了质的飞越，不仅仅是服务拆分，微服务是一整套的服务治理的架构，具备整套的设施

以往的应用程序开发中，应用程序都是单体型，在开发和部署上比较方便，但是随着业务的不断增加，开发迭代和性能瓶颈等问题都会增加开发难度。微服务正是为解决这一设计问题而应运而生，微服务在将复杂系统切分为数十乃至上百个小服务的同时，这些小服务带来了语言和框架选择上的灵活性，缩短应用开发上线时间，可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势

特性

（1）每个服务为独立的业务开发，单独部署，跑在自己的进程中
（2）自动化测试、部署、运维（DevOps）
（3）快速演化、快速迭代
（4）整个业务由一系列的独立的服务共同组成系统
（5）高度容错性、高可用、高并发

具备能力

微服务被拆分为多个微服务进程后，进程内的方法调用变成了进程间的远程调用，这种变化会带来分布式系统的一系列问题，而实现微服务架构概念的框架解决了以下问题

（1）注册中心

应用启动自动注册，调用方自动发现上线应用。服务异常自动隔离。

（2）配置中心、消息中心

配置中心：多环境配置管理，支持在线管理配置信息，客户端实时生效。支持版本管理，快速回滚
消息中心：服务间异步通信的总线

（3）负载均衡

服务调用服务会采用一定的分发策略，一般是客户端分发策略

（4）服务间通信

使用HTTP或RPC协议进行服务调用，REST、gRPC、Thrift、hession等

（5）服务降级、熔断、重试

降级：服务或依赖服务异常时，返回保底数据
熔断：若依赖服务多次失效，则断开，不再尝试调用，直接返回降级值
重试：熔断后，定期探测依赖服务可用性，若恢复则恢复调用

（6）服务发布与回滚

红绿部署、灰度、AB Test等发布策略，可快速回滚应用

（7）服务动态伸缩、容器化

根据服务负载情况，可快速手动或自动进行节点增加和减少

（8）服务监控与告警

服务定期健康检察、指标统计、异常告警通知运维

（9）请求缓存与合并

服务间调用相同请求缓存，类似请求合并成批量请求，减少服务间通信，提高性能

（10）服务网关

用户请求过载时进行限流、排队，过载保护，黑白名单、异常用户过滤拦截等

（11）服务依赖、文档、Mock Server、版本管理

自动生成接口文档，接口版本化管理，Mock接口等

（12）日志收集、追踪、分析

集中收集各服务日志汇总，方便排障、问题调查、应用日志分析等

（13）性能监测APM

对各服务性能进行监测与分析，为服务优化提供数据支持

微服务存在的技术点

微服务存在的技术点可以得到微服务基础架构的如下关键点

微服务架构挑战

（1）服务规模大，部署、运维、管理难度大
（2）服务间调用关系复杂，调用链路长，排除故障难度大
（3）服务间通信成本变大，性能和容错带来的挑战
（4）服务间依赖较多，系统集成、测试难度变大
（5）开发人员技术能力挑战，各服务间重复代码，重复建设等
（6）集群规模大，功能性能监控、告警带来的挑战
（7）大规模分布式，数据一致性带来的挑战
（8）需求和版本协调复杂度大大增加，测试难度也增加
（9）对基础架构要求大大提高，规模大幅增加

微服务优缺点

优点

（1）每个微服务都很小，能够聚焦一个指定的业务功能或业务需求
（2）能够被小团队单独开发，这个小团队是2到5人的开发人员组成
（3）松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的
（4）能使用不同的语言开发，如Java、Python、PHP、C#等
（5）允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Travis CI等工具
（6）一个团队的新成员能够更快投入生产
（7）易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值
（8）方便融合最新技术
（9）只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合
（10）能够即时被要求扩展
（11）能部署中低端配置的服务器上
（12）易于和第三方应用系统集成
（13）每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库
通过分解巨大单体式应用为多个服务方法解决了复杂性问题，每个微服务相对较小，每个单体应用不局限于固定的技术栈，开发者可以自由选择开发技术，提供API服务。
每个微服务独立的开发，部署
单一职责功能，每个服务都很简单，只关注于一个业务功能
易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务
改善故障隔离。一个服务宕机不会影响其他的服务

缺点

（1）开发者需要应对创建分布式系统所产生的额外的复杂因素
目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发
测试工作更加困难
需要采用服务间的通讯机制
很难在不采用分布式事务的情况下跨服务实现功能
跨服务实现要求功能要求团队之间的紧密协作

（2）部署复杂
（3）内存占用量更高

服务框架的递变

第一代服务框架

代表：Dubbo（Java）、Orleans（.Net）等
特点：和语言绑定紧密

第二代服务框架

代表：Spring Cloud等
现状：适合混合式开发（例如借助Steeltoe OSS可以让ASP.Net Core与Spring Cloud集成），正值当年

第三代服务框架

代表：Service Mesh（服务网格） => 例如Service Fabric、lstio、Linkerd、Conduit等
现状：在快速发展中，更新迭代比较快

未来（目测不久）主流的服务架构和技术栈

基础的云平台为微服务提供了资源能力（计算、存储和网络等），容器作为最小工作单元被Kubernetes调度和编排，Service Mesh（服务网格）管理微服务的服务通信，最后通过API Gateway向外暴露微服务的业务接口

目前，大型企业的项目组已经在采用这种技术架构了，服务网格采用的是Linkerd，容器编排采用的是K8S，Spring Cloud已经没用了。但是，不代表Spring Cloud没有学习的意义，对于中小型项目团队，Spring Cloud仍然是快速首选

微服务技术框架

微服务框架可以分为侵入式和非侵入式（两种）

什么是侵入式微服务框架？

以微服务框架Spring Cloud来进行说明，在微服务框架中使用Eruka Server作为服务注册中心，在微服务单元上配置使用Eureka Client向注册中心进行注册，这样就会带来一个问题，在旧代码或者非JAVA代码（比如Python）中使用Spring Cloud微服务框架，这样就需要对旧代码及非JAVA代码进行微服务化的改造。Spring Cloud是侵入式的微服务框架，侵入式微服务架构还存在Dubbo框架

Spring Cloud

Spring Cloud作为一个微服务的开发框架，包括了很多的组件，其中包括Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius）、Spring Cloud Config、Spring Cloud Bus、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Task、Spring Cloud Zookeeper、Spring Cloud Connectors、Spring Cloud Starters、Spring Cloud CLI等

另外Spring Boot为Spring Cloud提供一个简化基于Spring的开发环境，可以适应Spring Boot快速开发单个微服务
Spring Cloud为开发人员提供了工具，以快速构建分布式系统中的一些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，群集状态）。分布式系统的协调导致样板式样，并且使用Spring Cloud开发人员可以快速站起来实现这些样板的服务和应用程序。它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心以及Cloud Foundry等托管平台

Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。核心部分包含：
（1）远程通讯
提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式

（2）集群容错
提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持

（3）自动发现
基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器

Spring Cloud与Dubbo比较

一个关于Spring Cloud和Dubbo很有意思的比喻，使用Dubbo构建的微服务架构就像组装电脑，各个环节的可选自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，但是如果是一个高手，这一切都不存在问题。Spring Cloud就像品牌机，在Spring Source的整合下，做了大量兼容性的测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外配件时，需要对配件足够的了解

什么是非侵入式微服务框架？

以微服务框架中微服务的注册来进行说明，比如将服务注册和服务调用从现有服务中抽离出来，形成一个服务代理。该服务代理也叫做Sidecar，负责找到目的服务并负责通讯的可靠性和安全等问题。当服务大量部署时，随着服务部署的Sidecar代理之间的链接形成了一个如下图所示的网格，该网格成为微服务的通讯基础设施层，承载微服务之间的所有流量，被称为Service Mesh（服务网格）。非侵入式的微服务框架的比较有代表性的方案有Istio和Conduit

Istio

Istio是一个用来连接、管理和保护微服务的开放平台。Istio提供一种简单的方式来建立已部署服务网络，具备负载均衡、服务间认证、监控等功能，而不需要改动任何服务代码。想要为服务增加Istio的支持，只需要在环境中部署一个特殊的边车（sidecar），使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信
Istio目前仅支持在Kubernetes上的服务部署，但未来版本中将支持其他环境

Conduit

Conduit是为Kubernetes设计的一个超轻型服务网格服务，它可透明地管理在Kubernetes上运行的服务的运行时通信，使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能，而无需更改代码
Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板，并对外提供北向接口

系统架构的演变（重点了解）

随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？

1.集中式架构（单一应用）

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本
用于简化增删改查工作量的数据访问框架（ORM）是影响项目开发的关键

问题：
（1）代码耦合，开发维护困难
（2）无法针对不同模块进行针对性优化
（3）无法水平扩展
（4）单点容错率低，并发能力差

2.垂直拆分

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，根据业务功能对系统进行拆分，拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键

优点：
（1）系统拆分实现了流量分担，解决了并发问题
（2）可以针对不同模块进行优化
（3）方便水平扩展，负载均衡，容错率提高

缺点：
（1）系统间相互独立，会有很多重复开发工作，影响开发效率

3.分布式服务

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

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键

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

缺点：
（1）系统间耦合度变高，调用关系错综复杂，难以维护

4.流动计算架构（SOA）

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和**治理中心（SOA）**是关键

SOA（Service-Oriented Architecture，面向服务的架构）

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互

一种思想，一种方法论，一种分布式的服务架构。SOA解决多服务凌乱问题，SOA架构解决数据服务的复杂程度，同时SOA又有一个名字，叫做服务治理

优点：
（1）降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如何调用，只要通过统一标准找数据总线就可以
（2）程序之间关系服务简单
（3）识别哪些程序有问题（挂掉）

缺点：
（1）提升了系统的复杂程度，性能有相应影响
（2）服务间会有依赖关系，一旦某个环节出错会影响较大
（3）服务关系复杂，运维、测试部署困难，不符合DevOps思想

统一标准：各系统的协议、地址、交互方式。
新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，并不关心如何找到其他子系统，只找数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个指路人的作用

以前出现了什么问题？
（1）服务越来越多，需要管理每个服务的地址
（2）调用关系错综复杂，难以理清依赖关系
（3）服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？
（1）服务注册中心。实现服务自动注册和发现，无需人为记录服务地址
（2）服务自动订阅。服务列表自动推送，服务调用透明化，无需关心依赖关系
（3）动态监控服务状态监控报告，人为控制服务状态

5.微服务

就目前而言，业界对微服务并没有一个统一的标准的定义。但通常而言，微服务架构是一种架构模式或者架构风格，提倡将单一应用程序划分成一组小的服务。每个服务运行在其独立的进程中。服务之间互相协调互相配合，为用户提供最终价值。服务之间采取轻量级的通信机制互相沟通（通常是基于HTTP的Restful API）。每个服务都围绕这具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量的避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写这些服务，也可以使用不同的数据存储

服务调用方式

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

①：RPC

Remote Produce Call远程过程调用，类似的还有RMI 远程方法调用。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表

②：HTTP

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

Dubbo、Spring Cloud选择