微服务:分解应用以实现可部署性和可扩展性微服务:分解应用以实现可部署性和可扩展性
本文描述了日渐流行的微服务架构模式。微服务背后大的理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务,
这些服务能够随着时间的流逝而演化。微服务这个术语强烈建议服务应该是很小的。
社区中有些人甚至建议构建10-100代码行(LOC)的服务。但是,尽管很小的服务是我们想要的,但这不应该是主要的目
标。你应该致力于将系统分解为服务,以解决下面所讨论的开发和部署问题。一些服务可能确实会很微小,但有些可能会非常
大。
微服务架构的本质并不新鲜。分布式系统的理念历史非常悠久。微服务架构也很类似于SOA。
它甚至曾经被称为轻量级或细粒度的SOA。确实是这样,思考微服务架构的一种方式就是将其视为没有商用和沉重WS*以及
ESB的SOA。尽管这不是一个全新的理念,但微服务架构还是值得讨论的,因为它不同于传统的SOA,更为重要的是它能够
解决目前很多组织所遇到的问题。
在本文中,你将会学习到采用微服务架构的驱动力以及如何将其与更为传统的、整体(monolithic)架构进行对比。我们会讨
论微服务架构所能带来的收益及其缺点。你能够学习到如何解决使用微服务架构时所遇到的关键技术挑战,包括服务间的通信
以及分布式数据管理。
整体架构(有时是有害的)
从最早为Web系统开发应用开始,最为广泛使用的企业应用架构就是将应用所有的服务端组件打包成一个单元。很多的企业
级Java应用由一个WAR或EAR文件所组成。其他语言,如Ruby甚至C++,所编写的应用也是同样的情况。
比如,让我们假设一下,你正在构建一个在线商店,它会接受顾客的订单、检查库存以及可用的额度,然后完成运送。应用很
可能构建成如图1所示的样子。
图1——整体的架构
应用有多个组件组成,包括StoreFront UI,它实现了用户界面,以及用来管理产品目录、处理订单和管理用户账号的服务。这
些服务共享领域模型,模型中包含了实体,如Product、Order和Customer。
尽管有一个逻辑上的模块化设计,但应用还是会作为一个整体进行部署。例如,如果你使用Java的话,那么应用会由一个
WAR文件组成,它会运行在Web容器中,如Tomcat。如果应用是Rails版本的话,它会由一个目录结构组成,如果使用
Apache/Nginx的话,可以使用Phusion Passenger部署,或者使用Tomcat的时候,利用JRuby进行部署。
这种所谓的整体架构会有很多的优点。整体架构开发起来较为容易,因为IDE和其他的开发工具都是面向开发单个应用的。它
们测试起来很容易,因为你只需要启动一个应用。整体架构的应用也很容易进行部署,因为你只需要将部署单元——一个文件
或目录——复制到运行对应种类服务器的机器上就可以了。
这种方式对于相对小的应用来说,工作起来是很好的。但是,对于复杂应用来讲,整体架构就会变得很笨重了。对于开发者来
说,大型的整体架构应用会很难理解和维护。对于频繁部署来说,这也是一个障碍。要部署某个应用组件的变更,你必须要构
建和部署整个庞大的应用,这会很复杂、有风险、耗时,并且需要与众多的开发人员协调从而导致很长的测试周期。
整体架构使得很难去试验和采用新技术。例如,如果不重写整个应用的话,很难去尝试使用新的基础设施框架,而重写整个应
用是有风险且不现实的。所导致的结果就是,你必须坚守项目初期所选择的技术。换句话说,整体架构不能进行扩展以支持大
型的、长期存在的应用。
将应用分解为服务
幸运的是,有很多其他的架构风格来支持可扩展性。在《可扩展性的艺术》(The Art of Scalability)一书中,描述了很有用
的三维可扩展性模型:扩展性立方,如图2所示。