微服务微服务-分解应用程序从而实现更好的部署特性及可伸缩性分解应用程序从而实现更好的部署特性及可伸缩性
微服务:分解应用程序从而实现更好的部署特性及可伸缩性
本文描述了越来越受欢迎的微服务架构模式(Microservice architecture pattern)。微服务背后的大创意是将大型的、复杂
的、长期的应用程序架构为随时进化的紧密结合的一组服务。术语微服务强烈建议服务应当是微小的。
社区中甚至提倡构建10-100个LOC服务。然而,拥有微小的服务是可取的,但其不应该是主要目的。你应该旨在将你的系统
分解为服务,从而解决下面讨论的开发及部署问题。一些服务确实应当是微小的,其它的则有可能是相当大的。
微服务架构的本质并不是一个新事物。分布式系统的概念是非常古老的。微服务架构也类似于SOA。
在本文中,你将学习使用微服务架构的动机以及与更传统的架构-单块架构(monolithic architecture)的比较。我们讨论了微
服务的优点和缺点。你将学习如何通过微服务架构来解决一些关键的技术挑战,包括服务间通讯和分布式数据管理。微服务甚
至被称为轻量级的或细粒度的SOA。确实,某种意义上说微服务是非商业化的不能感知WS*和ESB包的SOA。尽管微服务并
不是新鲜的玩意,但是仍值得讨论,因为它与传统的SOA是不同的,更重要的是,它解决了许多组织当前遭受的很多问题。
(有时是邪恶的)单块架构
开发web程序的最早期时间,最被广泛使用的企业程序架构是将程序的服务器端组件打包为单个单元。很多企业Java应用程序
由单个WAR或EAR文件组成。其它语言(比如Ruby,甚至C++)编写的应用程序也大抵如此。
让我们想象一下,例如你在构建一个在线商店,从客户那里获取订单,验证清单及可用的信用卡,然后运送。你构建的程序与
图1所示会非常相似。
图 1单块架构
该应用程序由好几个组件组成。包括了存储前端UI,其实现了用户接口,和服务一起管理产品分类,处理订单和管理客户的账
户。这些服务共享一个由多个实体组成的领域模型,实体包括产品,定点和客户等。
尽管该程序拥有一个逻辑清晰的模型设计,但仍是一个单块架构。例如,如果你是使用Java,则该应用程序将由一个单独的
WAR文件组成,并且运行在一个web容器中(比如Tomcat)。该程序的Rails版本可能会有一个具有一定层级结构的目录组
成,部署也使用该目录,比如使用Phusion Passenger部署在Apache/Nginx,或者使用JRuby部署在Tomcat。
这种所谓的单块架构有一定的优点。单块架构的应用程序非常容易开发,因为IDE及其它开发工具都适合开发单个应用程序。
这些程序也很容易被测试,你只需启动一个程序即可。单块架构的应用程序也很容易部署,因为你只需复制开发单元(一个文
件或目录)到一个运行者相应服务容器的机器即可。
相对而言该方式更适用于小程序。然而,单块架构在复杂的程序中很难驾驭。一个庞大的单块程序对于开发者来说很难理解和
维护。它对频繁改动的开发过程来说也是一种阻碍。为了对某个程序组件做修改,你不得不构建和部署整个程序,这相当复
杂,风险极大,也比较耗时,需要很多开发者共同协作,还需要较长的测试周期。
单块架构也使得试用和采用新的技术变得困难。例如,尝试一个新的基础设施框架而不重写整个程序是非常困难的,风险又大
又不现实。因此,你经常被项目开始时你做的技术选型阻塞。换句话说,单块架构对于支持大型的,周期长的应用程序并不具
备伸缩性。
将应用程序分解为服务
幸运的是,有其它的具有可伸缩性的架构风格。《The Art of Scalability》一书中描述了真实有用的三维伸缩性模型:伸缩性
立方体,如图2所示。