背景
在开发服务端企业应用时,应用需要支持各种不同类型的客户端,比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API,并通过Web Service或者消息代理与其它应用实现集成。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应,来处理请求(HTTP请求与消息)。
应用采用多层架构或者六角架构,主要由以下几类不同组件构成:
不同逻辑组件分别响应应用中的不同功能模块。
问题
应用的部署架构是什么?
需求
方案
用Scale Cube方法(特别是Y轴扩展)设计应用架构,将应用程序按功能拆分为一组互相协作的服务。每个服务实现一组特定、相关的功能。举例来说,一个应用程序可能由订单管理服务、客户管理服务等多个服务构成。
服务间的通信则可由HTTP/REST等同步协议或者AMQP等异步协议实现。
服务可以彼此独立开发与部署。
每个服务皆有自己的数据库,从而保证其与其它服务解耦。在必要时,可利用数据库复制机制或者应用层事件机制,维护数据库之间的数据一致性。
示例
假设需要构建一款电子商务应用程序,使其能够接收来自客户的订单、验证库存信息与可用信用额度,而后进行发货。该应用程序会包含多个组件,其中StoreFrontUI负责实现用户界面,而其它后端服务则分别负责检查信用额度、维护库存信息以及发送订单。
此应用程序被部署为一组服务集合。
结果
此类解决方案拥有以下优势:
但这类解决方案中也存在着以下弊端:
应用此类方案带来的挑战在于如何把握好时机。在开发应用程序的最初版本时,大家往往不会面临需要使用微服务架构才能解决的问题。另外,使用复杂的分布式架构会拖慢开发流程。对于初创企业,其面临的最大挑战往往在于如何快速发展商业模式及附属应用。微服务架构中的Y轴拆分方式可能使应用更加难以迅速迭代。但是,如果当面临需要解决扩展性问题的时候再去进行功能拆分,单体应用的复杂依赖性使其很难被分解为服务集合。
另一项挑战在于如何将系统拆分为多个微服务。这虽然很棘手但还是有些可行之策。方法之一是根据“动词”或者用例进行服务划分。举例来说,我们经常会在电子商务应用中发现有单独的“发货”服务用于处理已完成订单。另一种常见的“动词”划分方式是实现登录用例的“登录”服务。
另外一种划分方式是根据“名词”或者资源进行系统划分。这类服务负责利用特定的实体/资源完成一系列操作。举例来说,大家可能会在电子商务系统当中发现有“库存”服务用于跟踪货物的库存。
在理想情况下,每项服务都应只面向一小部分职责。Bob Martin曾提出根据单一责任原则(Single Responsibility Principle,简称SRP)进行类的设计。SRP会用单一变更理由去定义一个类的职责:一个类的状态变更只能由一个原因导致。同理,我们也可以在微服务设计当中引入SRP。
另一项可用于指导服务设计的是Unix工具的设计思路。Unix提供大量工具选项,包括grep、cat以及find等等。每种工具都只负责实现一项功能,而且功能良好,它们可以通过Shell脚本与其它工具结合进而执行复杂的任务。
相关模式
微服务相关模式有很多,其中包括:
已知案例
众多大型网站将单体架构发展为微服务架构,其中包括Netflix、Amazon与eBay等。
作为一个热门视频流服务,Netflix利用一套大规模的SOA架构承载着高于30%的互联网流量。该公司每天需要处理来自800多种设备的10亿多次视频流API请求。平均每次API调用会在后端服务中产生6次后续调用。
Amazon.com 最初采用一套双层架构。为了扩展业务规模,其决定迁移至一套由数百项后端服务构成的SOA架构。多个应用调用这些服务,其中包括Amazon.com网站和Web服务API。Amazon.com网站需要调用100到150个服务方可获取到构建一个Web页面所需的全部数据。
作为拍卖网站,eBay.com也是从单体架构逐步转向SOA架构的。其应用层由多个独立应用构成。每个应用负责实现完成一组特定功能的业务逻辑,例如购买或者出售。每个应用皆利用X轴进行拆分,部分应用(例如搜索)以Z轴进行拆分。eBay.com还在数据库层采用了X、Y与Z轴相结合的扩展方式。
原文链接