小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效( 二 ) 什么是微服务模式随着网络基础设施的高

单体地狱的银弹-微服务架构软件架构其实对功能性需求影响并不大。事实上，在任何架构甚至是一团糟的架构之上，你都可以实现一组用例（应用的功能性需求）架构的重要性在于它影响了应用的非功能性需求，也称为质量属性或者其他的能力。随着 FTGO 应用的增长，各种质量属性和问题都浮出水面，最显著的就是影响软件交付速度的可维护性、可扩展性和可测试性。训练有素的团队可以减缓项目陷入单体地狱的速度。团队成员可以努力维护他们的模块化应用。他们也可以编写全面的自动化测试。但是另一方面，他们无法避免大型团队在单体应用程序上协同工作的问题，也不能解决日益过时的技术栈问题。团队所能做的就是延缓项目陷入单体地狱的速度，但这是不可避免的。为了逃避单体地狱，他们必须迁移到新架构：微服务架构。
今天，针对大型复杂应用的开发，越来越多的共识趋向于考虑使用微服务架构。但微服务到底是什么？不幸的是，微服务这个叫法本身暗示和强调了尺寸。针对微服务架构有多种定义。有些仅仅是在字面意义上做了定义：服务应该是微小的不超过 100 行代码，等等。另外有些定义要求服务的开发周期必须被限制在两周之内。曾在 Netflix 工作的著名架构师Adrian Cockcroft 把微服务架构定义为面向服务的架构，它们由松耦合和具有边界上下文的元素组成。这个定义不错，但仍旧有些复杂难懂。立方体模型会是更好的定义。
扩展立方体和服务

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

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

Z 轴扩展：根据请求的属性路由请求Z 轴扩展也需要运行单体应用程序的多个实例，但不同于 X 轴扩展，每个实例仅负责数据的一个子集。图 1-5 展示了 Z 轴扩展的工作原理。置于前端的路由器使用请求中的特定属性将请求路由到适当的实例。例如，应用程序可能会使用请求中包含的 userId 来路由请求。在这个例子中，每个应用程序实例负责一部分用户。该路由器使用请求 Authorization头部指定的 userId 来从 N 个相同的应用程序实例中选择一个。对于应用程序需要处理增加的事务和数据量时， Z 轴扩展是一种很好的扩展方式

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

服务本质上是一个麻雀虽小但五脏俱全的应用程序，它实现了一组相关的功能，例如订单管理、客户管理等。服务可以在需要的时候借助 X 轴或 Z 轴方式进行扩展。例如，订单服务可以被部署为一组负载均衡的服务实例。微服务架构的概括性定义是：把应用程序功能性分解为一组服务的架构风格。请注意这个定义中并没有包含任何与规模有关的内容。重要的是，每一个服务都是由一组专注的、内聚的功能职责组成。
微服务架构的好处和弊端优点大型的复杂应用程序可以持续交付和持续部署