微服务架构定义
微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。
微服务架构特点
根据微服务 Microservices 之父马丁.福勒的描述，我总结了以下6点：
1.一组小的服务：大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可；
2.独立的进程：比如部署在 java的tomcats等；
3.轻量级的通信：比如：典型的http协议；
4.基于业务能力：类似用户服务，商品服务等等；
5.独立部署：迭代速度快；
6.无集中式管理：无须统一技术栈，可以根据不同的服务或者团队进行灵活选择。
什么时候需要微服务架构
从生产力和系统的复杂性这两个方面来看，公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。
这个时候系统业务量较小，可以直接Java应用程序打包为War包部署在一台服务器上，整体架构如下图所示：
这种将所有功能，都部署在一个web容器中运行的系统，就叫做单体架构，也叫巨石型应用。
单体应用的优点在于：单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。
随着公司的发展，业务复杂性慢慢提高，以及访问量越来越大，会出现如下情况：
- 编译时间过长;
- 回归测试周期过长;
- 开发效率降低，因为所有业务都混在一起；
- 团队扩展了，需要分工明确了，按照业务来发展，大家都高效；
这时候就可以采用微服务来提升生产力了，至于这个转化的点，需要团队的架构师来进行各方面衡量，就个人经验而言，团队发展到百人以上，采用微服务就很有必要了。
有些架构师是具有微服务架构能力，所以设计系统时就直接设计成了微服务，而不是通过单服务慢慢演化发展成微服务。
在这里我并不推荐这种做法，因为一开始对业务领域并不是很了解，并且业务模式还没有得到验证，这时候上微服务风险比较高，很有可能失败。
所以建议大家在单服务的应用成熟时，并且对业务领域比较熟悉的时候，如果发现单服务无法适应业务发展时，再考虑微服务架构。
微服务架构组件
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置。
比如：以Spring Cloud为代表的微服务框架，都会实现以上的微服务组件。
1.服务注册中心
注册系统中所有服务的地方，所有的服务都会注册在这里。
2.服务注册
服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
3.服务发现
服务调用方从服务注册中心，找到自己需要调用服务的地址。
4.负载均衡
服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。
5.服务容错
通过熔断器等一系列的服务保护机制，保护服务调用不会出现大面积的雪崩。
6.服务网关
服务网关也称为API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
7.分布式配置中心
将本地化的配置信息，比如：properties、yml等配置信息，注册到配置中心，实现程序包在开发、测试、生产环境的无差别性方便程序迁移。
微服务架构有哪些
目前国内企业使用的微服务架构：主要是：
- Spring Cloud
- Spring Cloud Alibaba
- ServiceMesh这三套
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，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。
Service Mesh，是一个形象化的词语表达：Service（服务）和Mesh（网格），它描述了服务间的依赖形态，就像下面这张网一样。
ServiceMesh一般的架构如下图所示：
Service Mesh架构图从上图可以看到，业务所有的流量都转发到Service Mesh的代理服务Sidecar中。
Sidecar也称为边车模式，因为类似连接到摩托车的边车，从而得名。
如下图所示:
在Sidecar模式中，“边车”与父应用程序（即业务服务）是两个独立的进程，“边车”附加到业务服务，并为应用提供支持功能，如微服务架构中的基本通信。
总体来说，Service Mesh帮助应用程序在复杂的软件架构和网络中建立稳定的通信机制。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》