以前转载过一篇对 Martin Fowler 大师写的微服务架构的说明文章:《微服务(Microservices)》。今天再转载一篇对于这个架构的优缺点进行总结的文章。html
转载自:《微服务,让开发过程更简单仍是更复杂?》、《有关微服务架构的争论:更简单仍是更复杂?》。数据库
随着DevOps、持续交付等理念的深刻人心,微服务架构开始走进咱们的视野。编程
那么微服务是业界期待已久的解决方案么?或者说微服务要比总体解决方案更加简单?网络
让咱们先对微服务下个定义:架构
微服务是用一组小服务的方式来构建一个应用,服务独立运行在不一样的进程中,服务之间经过轻量的通信机制(如RESTful接口)来交互,而且服务能够经过自动化部署方式独立部署。正由于微服务架构中,服务之间是相互独立的,因此不一样的服务可使用不一样的语言来开发,或者根据业务的需求使用不一样类型的数据库。运维
来自ThoughtWorks的James Lewis和Martin Fowler分享了他们对微服务架构的理解以及见解。文章中做者详细介绍了微服务的特色以及相对于传统架构的微服务架构的优点。异步
微服务的一些优点是显而易见的:编程语言
- 服务简单,只关注一个业务功能
在James看来,传统的总体风格的架构在构建部署和扩展伸缩方面有很大的局限性,其服务端应用就像是一块铁板,笨重且不可拆分,系统中任何程序的改变都须要整个应用从新构建和部署新版本。在进行水平扩展时也只能整个系统扩展,而不能针对某一个功能模块进行扩展。
而微服务架构将系统以组件化的方式分解为多个服务,服务之间相对独立且松耦合,单一功能的改变只须要从新构建部署相应的服务便可。
- 每一个微服务可由不一样团队开发
传统的开发模式在分工时每每以技术为单位,好比UI团队、服务端团队和数据库团队,这样的分工可能会致使任何功能上的改变都须要跨团队沟通和协调。而微服务则倡导围绕服务来分工,不一样的服务能够采用不一样的技术来实现,一个团队中应该包含开发所需的全部技能,好比用户体验、数据库、项目管理。
- 微服务是松散耦合的
微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能,微服务架构中服务是高内聚的,每一个服务都会处理相应的业务,全部的业务逻辑应该尽可能在服务内部处理,且服务间的通讯尽量的轻量化,好比使用Restful的方式。
- 可用不一样的编程语言与工具开发
传统的软件开发中常常会使用同一个技术平台来解决全部的问题,而经验代表使用合适的工具作合适的事情会让开发变得事半功倍。微服务架构天生就具备这样的特性,咱们可使用Node.js来开发一个简单的报表页面,使用C++来编写一个实时聊天组件。
微服务架构的引入为多样化持久保存数据提供可能,持久层可使用传统关系数据库和NoSQL。不一样于传统的应用,微服务架构中,咱们能够为每一个服务选择一个新的适合业务逻辑的数据库系统,好比MongoDB、PostgreSQL。这样作的好处是显而易见的,首先咱们能够根据业务类型(读多仍是写多等)来决定使用哪一种类型的数据库,其次这样能够减少单个数据库的负载。
James的文章在社区引发了普遍的讨论,Contino公司的CTO Benjamin Wootton撰文表示微服务并无想象中的那么好,并建议开发者在选用此架构时必定要慎重。Benjamin认为微服务架构时可能会面临下面一些挑战:分布式
- 运维开销
更多的服务也就意味着更多的运维,产品团队须要保证全部的相关服务都有完善的监控等基础设施,传统的架构开发者只须要保证一个应用正常运行,而如今却须要保证几十甚至上百道工序高效运转,这是一个艰巨的任务。
- DevOps要求
使用微服务架构后,开发团队须要保证一个Tomcat集群可用,保证一个数据库可用,这就意味着团队须要高品质的DevOps和自动化技术。而如今,这样的全栈式人才不多。
- 隐式接口
服务和服务之间经过接口来“联系”,当某一个服务更改接口格式时,可能涉及到此接口的全部服务都须要作调整。
- 重复劳动
在不少服务中可能都会使用到同一个功能,而这一功能点没有足够大到提供一个服务的程度,这个时候可能不一样的服务团队都会单独开发这一功能,重复的业务逻辑,这违背了良好的软件工程中的不少原则。
- 分布式系统的复杂性
微服务经过REST API或消息来将不一样的服务联系起来,这在以前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者须要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等,而面对如此多的微服务都须要分布式时,整个产品须要有一整套完整的机制来保证各个服务能够正常运转。
- 事务、异步、测试面临挑战
跨进程之间的事务、大量的异步处理、多个微服务之间的总体测试都须要有一整套的解决方案,而如今看起来,这些技术并无成熟。
总而言之,微服务架构有不少吸引人的地方,不过在拥抱微服务以前要认清它所带来的挑战。而每一种架构都有其优缺点,咱们须要根据项目业务和团队状况来选择合适的架构。微服务