在传统的整体应用程序中,所有组织功能都写入一个应用程序。有时它们按类型分组,例如 Controller,View,Model。其他时候,可能在较大的应用程序中,功能由关注点或功能分开。所以我们可能会针对一些功能进行分模块,但是最终所有的功能,代码还是一个整体。
扩展立方体和服务 如下图图书,图片摘自,微服务架构设计
X轴扩展:在多个实例之间实现请求的负载均衡
X轴扩展是扩展单体应用程序的常用方法。下图展示了X轴扩展的工作原理。在负载均衡器之后运行应用程序的多个实例。负载均衡器在N个相同的实例之间分配请求。这是提高应用程序吞吐量和可用性的好方法。如下图所示,图片摘自微服务架构设计
Z轴扩展:根据请求的属性路由请求
Z轴扩展也需要运行单体应用程序的多个实例,但不同X轴扩展,每个实例仅负责数据的一个子集。图1-5展示了Z轴扩展的工作原理。置于前端的路由器使用请求中的特定属性将请求路由到适当的实例。例如,应用程序可能会使用请求中包含userId来路由请求。如下图所示,图片摘自微服务架构设计
Y轴扩展:根据功能把应用拆分为服务
X轴和Z轴扩展有效地提升了应用的吞吐量和可用性,然而这两种方式都没有解决日益增长的开发问题和应用复杂性。为了解决这些问题,我们需要采用Y轴扩展,也就是功能性分解。Y轴扩展把一个单体应用分成了一组服务。如下图所示,图片摘自微服务架构设计
服务本质上是一个麻雀虽小但五脏俱全的应用程序,它实现了一组相关的功能,例如订单管理、客户管理等。服务可以在需要的时候借助X轴或Z轴方式进行扩展。列如,订单服务可以被部署为一组负载均衡的服务实例。
克里斯·理查森(微服务架构设计模式作者) 对微服务架构的概括定义是:把应用程序功能性分解为一组服务的架构风格。请注意这个定义中并没有包含任何与规模有关的内容。重要的是,每一个服务都是由一组专注的、内聚的功能职责组成。
微服务架构作为模块化的一种形式
模块化是开发大型、复杂应用程序的基础。例如微信、支付宝这样的现代应用程序规模太大,很难作为一个整体开发,也没有人可以完全理解。为了让不同的人开发和理解,大型应用需要拆分模块。在单体应用中,模块通常由一组编程语言所提供的结构。但是随着时间的推移和反复的开发迭代,单体应用往往会蜕变成一个大泥球。
微服务架构使用服务作为模块化的单元。服务的API为它自身构筑了一个不可逾越的边界,你无法越过API去访问服务内部的类,这与采用包的单体应用完全不同。因此模块化的服务更容易随着时间推移而不断演化。微服务架构也带来其他的好处,例如,服务可以独立进行部署和扩展。每个服务都是一个独立的进程!
为什么要使用微服务?
复杂性 - 将功能拆分为微服务允许您将代码拆分为更小的块。它可以追溯到“做好一件好事”的旧unix谚语。整体性的结构倾向于允许域彼此紧密耦合,并且担心变得模糊。这会导致风险更高,更复杂的更新,可能存在更多错误并且更难以集成。
规模 - 在整体中,某些代码区域可能比其他区域更频繁地使用。例如12306的购票,查询余票,您只能扩展整个代码库。但是使用微服务架构的话,可以单独对这俩个服务进行扩容。
通过微服务,该分离允许您单独扩展单个服务。意味着更有效的水平缩放。这对于具有多个核心和区域等的云计算非常有效
每个服务都拥有自己的数据库
微服务架构的一个关键特性是每一个服务之间都是松耦合的,它们仅通过API进行通信。实现这种松耦合的方式之一,是每个服务都有自己的私有数据库。例如,一个线上商店来说,Order Service拥有一个包括ORDER表的数据库。
但是每一个微服务拥有它自己数据库的需求并不意味着每个服务都需要一个独立的数据库服务器。