微服务架构概述

什么是微服务架构

微服务架构方式在某种程度上来说是SOA架构持续发展的下一步愿景。总的来说，微服务是一种架构风格，对于大型复杂的业务系统，它的业务功能可以拆分成多个相互独立的部署的微服务模块，各个微服务模块之间是低耦合的，各个服务模块间通过各种远程协议进行同步、异步通信，各个微服务可以被独立部署、扩容、缩容以及升、降级。

微服务其本质上是一个麻雀虽小但五脏俱全的应用程序。它把应用程序功能性的分解为一组服务，实现了一组相关的功能的模块，为每一个服务提供一组专注的、高内聚的服务能力。并且这些服务可以在被需要的时候进行扩展。

扩展立方体和服务

 

X轴扩展：在多个实例之间实现请求的负载均衡

X轴扩展是扩展单体应用的常用方法。图1-4展示了X轴扩展的工作原理。在负载均衡器之后运行应用程序的多个实例。负载均衡器在N个相同的实例之间分配请求。这是提高应用程序吞吐量和可用性的好方法。

 

Z轴扩展：根据请求的属性路由请求

Z轴扩展也需要运行单体应用程序的多个实例，但不同于X轴扩展，每个实例仅负责数据的一个子集。图1-5展示了Z轴扩展的工作原理。

 

Y轴扩展：根据功能把应用拆分为服务

X轴和Z轴扩展有效的提升了应用的吞吐量和可用性，然而这两种方式都没有解决日益增长的开发问题和应用程序复杂性。为了解决这些问题，我们需要采用Y轴扩展，也就是功能性分解。Y轴扩展把一个单体应用分成了一组服务，如图1-6所示。

服务本质上是一个麻雀虽小五脏俱全的应用程序，它实现了一组相关的功能，例如订单管理等。服务可以再需要的时候借助X轴或Z轴方式进行扩展。

 

面向服务的SOA架构

面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议向其他组件提供服务或者消费，所以也是一种分布式架构。SOA是不同的业务建立不同的服务，服务之间的数据交互粗粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务逻辑变得可组合，并且每个服务都可以根据使用情况做到合理的分布式部署，从而让服务变得规范，高性能，高可用。

SOA架构中有两个主要角色：服务提供者（Provider）和服务消费者（Consumer）。阿里开源的是Dubbo是典型的实现。

SOA架构的优点：

1.模块拆分，使用接口通信，降低模块之间的耦合度。
2.项目拆分成若干个子项目，不同的团队负责不同的子项目。
3.增加一个功能只需要增加一个子项目，调用其他系统的接口即可。
4.可以灵活地分布式部署。

SOA架构的缺点：

1.系统之间的交互需要使用远程通信，接口开发增加工作量。

微服务架构和SOA架构的区别

微服务架构与SOA都是特定的架构风格，它们都以一系列服务的方式来把一个系统组织在一起，但它们之间有着巨大的差异。比如SOA和微服务架构采用完全不同的技术栈。SOA应用常常选择重量级的技术（SOAP和其他类似WS*标准）而微服务架构设计的应用程序更倾向于使用轻量级、开源的技术（REST、gRPC）。

总的来说SOA更偏向于较大的单体应用，而微服务典型的服务规模则是较小的服务。也就是说SOA和微服务架构在服务的粒度（规模）上有较大的区别，SOA更善于继承大型、复杂的单体应用程序。微服务则对服务的粒度控制的更小但不是必须做到最小，只是通常比较小而已。因此SOA应用通常包含若干个大型的服务，而微服务架构常常由数十个甚至上百个粒度更小的服务组成。

除此之外SOA和微服务在处理数据的方式上也有较大差异，SOA应用一般都有一个全局的数据模型，并且是共享的数据库。与之不同的是微服务架构中的每一个服务都有属于它最近的数据库和专属的领域模型。

微服务架构的优势

使大型的复杂应用程序可以持续交付和持续部署。

在软件开发过程中持续交付和持续部署是我们进行敏捷开发所必须的基础，同时也是DevOps理念的一部分。DevOps是一套快速、频繁、可靠的软件交付实践。合理的践行DevOps是作为一个合格开发者所必须具备的技术素养。高效能的DevOps团队通常在将软件部署到生产环境时面临更少的问题和故障。

微服务架构实现持续交付和持续部署的特性：

1.可测试性。自动化测试是持续集成和持续交付的一个重要环节。由于微服务每个服务的粒度都相对较小，编写测试用例和自动化测试将变得很容易。

2.可部署性。每个微服务都可独立于其他服务进行部署，如果该服务的开发人员要对该服务进行修改并部署，他们将不需要与其他开发人员协调就可以进行，因此将变更频繁部署到生产环境中要容易得多。

3.微服务使开发团队之间的耦合度更低。由于服务的粒度更小，我们可以让一、两个人或者一个小型团队来全权负责相关服务的开发和部署，每个团队独立于所有其他团队开发、部署、测试和扩展他们的服务，毫无疑问地是这将大大的提升技术团队的开发效率。

持续交付和持续部署可以为业务带来若干的价值：

1.缩短了产品或新功能的上线时间，能够快速的响应客户的需求和反馈。

2.能够提供客户所期望的可靠服务

3.开发人员更可以把时间花在更有价值的功能上，而不是四处担任救火队员，排查部署和交付中的各类系统环境问题。

每个服务都相对较小并且容易维护

由于服务的粒度比较小，开发人员更容易理解服务中的实现代码。并且较小规模的代码库不会把IDE工具拖慢，间接的提升了开发人员的工作效率，相应的代码更少服务启动的速度也会比大型的单体应用快很多，可以加速研发各个环节的效率。

每个服务可以独立部署和扩展

服务可以独立扩展，不论是采用X轴扩展的实例克隆，还是Z轴扩展的流量分区方式。此外，每个服务都可以部署在适合它们需求的硬件之上。

更容易实验和尝试新的技术

微服务架构可以消除对某项技术栈的长期依赖。原则上，当开发一个新的服务时，开发者可以自由选择适用于这个服务的任何语言和框架。更进一步，使用更好的编程语言和技术来重写一项服务变得有可能。这意味着，如果对一项新技术的尝试失败了，我们可以直接丢弃这部分工作而不至于给整个应用带来失败的风险。
 

具备更好的容错性

微服务架构可以实现更好的故障隔离，比如单个服务的内存泄露不会影响其他服务。

微服务架构的弊端

1.服务的拆分和定义是一项挑战：

采用微服务架构首当其冲的问题，就是根本没有一个具体的、良好定义的算法可以完成服务的拆分工作。与软件开发一样，服务的拆分和定义更像是一门艺术。

2.分布式系统带来的各种复杂性，使开发、测试和部署变得更困难：

使用微服务架构的另一个问题是开发人员必须处理创建分布式系统的额外复杂性。服务必须使用进程间通信。此外，必须设计服务来处理局部故障，并处理远程服务不可用或出现高延迟的各种情况。微服务架构还引入了显著的运维复杂性，要成功部署微服务，必须需要高度自动化的基础设施。

3.当部署跨越多个服务的功能时需要谨慎地协调更多开发团队：

必须制定一个发布计划，把服务按照依赖关系进行排序。

4.开发者需要思考到底应该在应用的什么阶段使用微服务架构：

在开发应用的第一个版本时，你通常不会遇到要微服务架构才能解决的问题。此外，使用精心设计的分布式架构将减缓开发速度。这对初创公司来说可能是个得不偿失的，其中最大的问题通常是在快速发展业务模型和维护一个优雅的应用架构之间的取舍。初创公司几乎肯定应该从单体的应用程序开始。但是稍后，当问题变为如何出合理复杂性时，那就是好将应用程序功能性的分解为一组服务的时候了。