在微服务架构模式下，将传统单体应用根据业务和技术需要，拆分为多个细粒度可独立开发、编译、部署、运行的微服务和微应用；每个微应用、微服务代码量小、相互独立，易于维护、编译、部署，开发迭代周期较短；每个微应用、微服务部署包体量小，服务启动和资源回收速度快，易于实现弹性伸缩，能够很好地满足高并发和访问量波动较大的应用场景；每个微应用、微服务独立部署，故障隔离性好，单个微应用、微服务出现问题不会导致整个业务应用不可用。借助以上优点，采用微服务进行业务应用开发，业务应用能够实现灰度发布、频繁部署，持续交付能力强，能够灵活快速地适应业务的持续发展变化。

1、概念

1.1 微服务

微服务是指以服务方式实现的不带界面的软件包，具有部署独立、通信轻量的特点，支撑单一业务逻辑的功能实现，通常用于跨专业的数据交互或并发量大的业务逻辑功能实现。

微服务特征如下：

轻量级通讯协议（REST或RPC）
不包含任何界面的业务逻辑实现服务软件包
以jar包形式发布
采用内嵌中间件运行
相对于其它微服务独立开发、编译、发布、部署、运行

1.2 微应用

微应用是指通过调用一个或者多个微服务，实现一组同类型的或紧密耦合的单一业务目标或业务场景的功能逻辑组合软件包，提供带界面的软件客户端，可通过PC、移动设备、大屏等各类终端设备实现人机交互。

微应用特征如下：

实现完整单一业务逻辑单元
按照业务职能拆分，必须在二级或以下职能进行拆分
提供人机操作界面
通过调用一个或多个微服务实现业务逻辑，不直接访问数据库
相对于其它微应用独立开发、编译、发布、部署、运行

1.3 单体应用

单体应用以传统软件架构理论为指导，采用单体架构风格进行设计、基于传统方式构建、在集中式架构中运行的应用。

单体应用特征如下：

以单一软件包开发、部署、运行，包含前后端全部功能实现
可对外提供数据交互服务接口
任何代码修改都需要全局重新构建、发布和停机部署
任意部分功能的运行异常可能会导致整个业务应用不可用

1.4 特征区别

对比项	单体应用	微应用	微服务
前端页面	包含	包含	不包含
划分粒度	粗	细	细
局部修改是否需要全局重新构建部署	需要	不需要	不需要
局部运行异常是否导致整个系统不可用	会	不会	不会
发布包格式	war包	war包	jar包
中间件	外置	外置	内嵌
是否对外提供服务接口	是	否	是
是否访问数据库	是	否	是

1.5 适用场景

微服务架构模式下，每个微服务、微应用体量较小，代码易于开发、维护、编译、部署；开发迭代周期短，运行故障隔离性好，利于灰度发布、频繁部署，持续交付能力强。因此，微应用、微服务适用于业务复杂、功能庞大、业务需求变化频繁（快速迭代），并发访问量波动较大，开发人员流动较频繁的业务应用。而对于业务稳定（如主要工作是改bug和数据）、迭代周期长（如几个月一次迭代）的项目则不适用。

单体应用架构模式下，所有业务逻辑在同一个进程内实现，功能间相互调用不需要网络通信，性能更高；无分布式事务、易于运维维护、不存在跨域问题等优点。因此，单体应用适用于业务简单、功能较少、业务需求比较稳定，并发访问量波动不大，开发人员比较稳定的业务应用。

2、微服务架构常用概念

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

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

上面的问题是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。

1111116

2.1 服务治理

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

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

2.2 服务调用

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

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

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

2.3 服务网关

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

客户端需要调用不同的url地址，增加难度
在一定的场景下，存在跨域请求的问题
每个微服务都需要进行单独的身份认证

针对这些问题，API网关顺势而生。API网关纸面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。

一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。

有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

1111117

2.4 服务容错

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

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

1111118

2.5 链路追踪

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

1111119

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

3.1 ServiceComb

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

官网地址：ServiceComb

3.2 SpringCloud

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

官网： https://spring.io/projects/spring-cloud
中文文档： https://www.springcloud.cc/
Spring Cloud中国社区：http://springcloud.cn/

主要组件：

注册中心Eureka: 拆分成多个服务之后，总得有个管理多个服务的模块吧，这就是注册中心的作用。起到服务注册和服务发现的作用。
网关Zuul: 拆分成多个服务之后，涉及到服务之间的调用吧，一个服务调用了三个服务的模块，那在这个服务里，配置三个调用地址，看起来是不是很麻烦呀，所以就出现了网关，所有的服务调用都调用到网关，然后在网关里配置路由，进行服务的转发，类似于代理的作用。当然网关需要配合注册中心进行使用，去发现转发到哪个服务上去。
负载均衡Ribbon: 网关找到请求发送到哪个服务后，如果这个服务做了集群，有多个实例，那该发送到哪个实例上呢，于是就出现了Ribbon组件，进行负载均衡。
远程调用方式Feign: 服务之间相互调用的时候，可以使用RestTemplate进行调用，SpringCloud也提供了Feign客户端访问，即提供了一种远程调用方式。
断路器Hystrix: SpringCloud提供了一个监控组件，用于监控服务接口的状态和断路情况。Hystrix Dashboard是个监控面板，提供了可视化界面查看服务调用的耗时等等。

3.3 SpringCloud Alibaba

SpringCloud Alibaba是阿里研发的一套微服务架构的落地技术方案，可以很好的兼容SpringCloud，此项目包含开发分布式应用微服务的必需组件，只需修改一些配置和注解，原生SpringCloud就可以接入到SpringCloud Alibaba中。

SpringCloud Alibaba提供了一些新组件，来落地微服务架构，阿里之所以要开发这套技术架构，主要是为了推广相关的产品，当然有付费产品。

3.3.1 主要功能

服务限流降级：默认支持 WebServlet、WebFlux， OpenFeign、RestTemplate、Spring Cloud Gateway， Zuul， Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。

服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。

分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。

分布式事务：使用 @GlobalTransactional 注解，高效并且对业务零侵入地解决分布式事务问题。

阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。

分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有Worker（schedulerx-client）上执行。

阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

3.3.2 开源组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

Dubbo： Apache Dubbo™ 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Arthas：开源的java动态追踪工具，基于字节码增强技术，功能非常强大。

3.3.3 商业组件

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

3.3.4 SpringCloud与Alibaba组件对比

	SpringCloud	SpringCloud Alibaba
注册中心	Eureka	nacos
消息中间件	无(第三方替代方案：rabbitmq)	RocketMQ
分布式事务解决方案	无(第三方替代方案：2pc)	Seata
分布式调度服务	无(第三方替代方案：xxl-job)	Alibaba Cloud SchedulerX
短信平台	无	Alibaba Cloud SMS
分布式配置中心	SpringCloudConfig	nacos
熔断降级	Hystrix	Sentinel
网关	zuul	gateway

4、微服务拆分原则

微服务拆分过程中需严格遵守高内聚、低耦合原则，同时结合项目的实际情况，综合考虑业务领域、功能稳定性、应用性能、团队以及技术等因素。

基于业务领域拆分，在领域模型设计时需对齐限界上下⽂，围绕业务领域按职责单一性、功能完整性进行拆分，避免过度拆分造成跨微服务的频繁调用。
基于业务变化频率和业务关联拆分，识别系统中的业务需求变动较频繁的功能，考虑业务变更频率与相关度，并对其进行拆分，降低敏态业务功能对稳态业务功能的影响。
基于应用性能拆分，考虑系统⾮功能性需求，识别系统中性能压力较大的模块，并优先对其进行拆分，提升整体性能，缩小潜在性能瓶颈模块的影响范围。
基于组织架构和团队规模，提高团队沟通效率。
基于不同功能的技术和架构异构以及系统复杂度
业务完整、职责单一的应用功能单元应当拆分为独立微服务。
具有重用性特点的公共功能应当拆分为独立微服务。
访问量较大、资源消耗较大、耗时较长的功能，应拆分为独立微服务。
一组强关联的数据对象的所有增删改操作，不要拆分到多个微服务中。
耦合性强、存在事务强一致性的业务，不要拆分到多个微服务内，尽可能避免分布式事务。
建议为每个微服务设计独立数据库进行支撑。

一个产品一般约定多少微服务?

十几个或者几十个，但不能超100个。

一个微服务对应多少数据库表？

一个微服务尽量不要超过10张数据库表。当然为了减少微服务的数量，也可以将微服务设计大一些，即一个微服务不要超过20张表。

目录CONTENT

微服务和微应用架构介绍