微服务定义
微服务是一种架构模式，它提倡将单一应用程序划，分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
微服务架构，服务之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。
为什么需要微服务？
一个系统业务量很小的时候，大部分Web工程的Java应用程序，打包为War包部署在一台服务器上。
比如：你正在构建一个在线商店系统，包含功能：用户、商品、下订单等功能，整体架构如下图所示：
这种将所有功能，都部署在一个web容器中运行的系统，就叫做单体架构，也叫巨石型应用。
单体应用的优点在于：单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
但是，对于大规模的复杂应用，单体架构应用会显得特别笨重，比如：
- 要修改一个地方就要将整个应用全部部署;
- 编译时间过长;
- 回归测试周期过长;
- 开发效率降低，因为所有业务都混在一起；
- 单体架构不利于更新技术框架，除非你愿意将系统全部重写(代价太高你愿意老板也不愿意)。
为了解决这些问题，就出现了微服务架构。
微服务架构
随着业务访问量越来越大，单体应用就会出现巨大的瓶颈，随意后期就会出现，按照业务为单位进行拆分，出现的微服务架构。
1.微服务优点
- 每个服务足够内聚，足够小，这样能聚焦一个指定的业务功能或业务需求；
- 开发效率提高，一个服务可能就是专一的只干一件事；
- 在开发阶段，或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果；
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
2.微服务缺点
- 分布式复杂性：在复杂程度上来说，微服务比单体建构要更为复杂些；
- 最终一致性：各个服务的团队，数据也是分散式治理，会出现不一致的问题；
- 运维复杂性：部署比单体项目复杂得多，运维更复杂；
- 测试复杂性：测试也会更复杂；
微服务特点
根据微服务 Microservices 之父马丁.福勒的描述，我总结了以下几点。
1. 独立业务模型
微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信
服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。
目前大家熟悉的 REST是实现服务间互相协作的轻量级通信机制之一，使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
3. 独立部署
不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会出现一定程度的改变，开发的也要有一定的运维职责。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4. 独立进程
每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而另一个服务运行在 Jetty 上，可以通过进程方式，不断的横向扩展整个服务。
5.不集中式管理
微服务架构，可以让团队各思其政的选择技术实现，不同的 Service 可以根据各自的需要选择不同的技术栈来实现其业务逻辑。
微服务框架
目前国内企业使用的微服务框架：主要是Spring Cloud和Spring Cloud Alibaba。
最为典型的就是Spring Cloud微服务框架 ，Spring Cloud是一套完整的微服务解决方案，它将市面上较好的微服务框架集成进来，从而简化了开发者的代码量。
Spring Cloud
Spring Cloud体系包含如下：
1.Eureka注册中心
拆分成多个服务之后，需要管理多个服务，Eureka 作为 Spring Cloud 框架的注册中心，起到服务注册和服务发现的作用。
上图简要描述了Eureka的基本架构，由3个角色组成：
1）Service Provider： 暴露服务的服务提供方；
2）Service Consumer：调用远程服务的服务消费方；
3）EureKa Server： 服务注册中心和服务发现中心；
2.Zuul 服务网关
Zuul 是 Spring Cloud 子项目的核心组件之一，可以作为微服务架构中的 API 网关使用，支持动态路由与过滤功能。
Zuul就是微服务网关的一种实现，Zuul作用：类似我们小区的保安，用于保护基本的安全等的作用。
Zuul 本质上是一个Web servlet应用，为微服务架构中的服务提供了统一的访问入口，客户端通过 API 网关访问相关服务。
3.Hystrix断路器
Hystrix的主要作用就是：提供服务隔离、熔断、降级机制。
4.Ribbon负载均衡
Ribbon主要作用是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。
当多个服务提供者时，Ribbon 可以根据负载均衡的算法，比如：如简单轮询、随机连接等，自动地选择需要调用的服务地址。
5.Feign远程调用方式
Feign是Spring Cloud组件中的一个轻量级Restful的HTTP服务客户端，通过 接口 + 注解的方式发起 HTTP 请求调用。
Feign 主要是帮助我们方便进行Rest API服务间的调用，Feign最大的作用就是减少 HTTP 远程调用的复杂性。
Feign实现了像调用本地方法一样调用远程方法，无感知远程HTTP 请求，类似于Dubbo Consumer直接调用Provider的接口方法。
Spring Cloud Alibaba
Spring Cloud Alibaba是阿里研发的一套微服务架构的落地技术方案，可以很好的兼容SpringCloud，可以简要理解为Spring Cloud的升级版。
Spring Cloud Alibaba体系包含如下图所示：
1.Sentinel流量控制
Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定性。
Sentinel的核心功能，如下图所示：
2.Nacos服务配置
Nacos是SpringCloudAlibaba架构中最重要的组件，Nacos 主要解决服务发现、配置和管理微服务。
3.RocketMQ消息中间件
RocketMQ是一个纯java、分布式、队列模型的开源消息中间件。
4.Dubbo远程通信
Dubbo是一款Java RPC框架，致力于提供高性能的RPC远程服务调用方案。
Dubbo角色，主要包含如下几个核心组件：
1)注册中心（registry）
生产者在此注册并发布内容，消费者在此订阅并接收发布的内容。
2)消费者（consumer）
客户端，从注册中心获取到方法，可以调用生产者中的方法。
3)生产者（provider）
服务端，生产内容，生产前需要依赖容器（先启动容器）。
4)容器（container）
生产者在启动执行的时候，必须依赖容器才能正常启动（默认依赖的是spring容器），
5)监控(Monitor)
统计服务的调用次数与时间等。
5.Seata分布式事务
Seata是一款阿里开源的分布式事务解决方案，Seata致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
Seata事务管理中有三个重要的组件角色，如下图所示：
三个组件相互协作，TC 以 Server 形式独立部署，TM和RM集成在应用中启动。
1.TC (Transaction Coordinator) 事务协调者
TC：维护全局和分支事务的状态，协调全局事务提交或回滚。
2.TM (Transaction Manager) 事务管理器
TM：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
3.RM (Resource Manager) -资源管理器
RM：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
下一代微服务框架
目前下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。
微服务的应用场景
微服务也不是一招鲜吃遍天，不是能够解决所有问题的万金油，它有其特定的适用场景。
那么哪些场景适合使用微服务架构呢？满足以下三个条件即可考虑：
- 团队规模较大，最好超过50人；
- 业务复杂度高，超过5个以上的子模块，业务功能较复杂；
- 项目需要长期迭代开发和维护，半年以上；
微服务架构的应用场景
比如:电商类的、微博类的、微信类、社交类的、支付类的、直播类的、游戏类、互联网类的、广告类到处都是。
这背后反映了架构的拆分，本质上反映的是业务的一个拆分，业务的快速发展技术也一定要快速发展，技术架构快速迭代，才能去适应业务快速发展的模型，这是它的本质的特征。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》