BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

有关微服务架构的争论:更简单还是更复杂?

| 作者 郭蕾 关注 9 他的粉丝 发布于 2014年5月29日. 估计阅读时间: 7 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

随着DevOps、持续交付等理念的深入人心,微服务(Microservices)架构开始走进我们的视野。微服务是用一组小服务的方式来构建一个应用,服务独立运行在不同的进程中,服务之间通过轻量的通讯机制(如RESTful接口)来交互,并且服务可以通过自动化部署方式独立部署。正因为微服务架构中的服务之间是相互独立的,所以不同的服务可以使用不同的语言来开发,或者根据业务的需求使用不同类型的数据库。3月底,来自ThoughtWorks的James Lewis和Martin Fowler分享了他们对微服务架构的理解以及看法。文章中作者详细介绍了微服务的特点以及相对于传统架构的微服务架构的优势。

在James看来,传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性,传统的整体(monolithic)风格的架构一般分为三部分:客户端用户界面(HTML页面和JavaScript程序)、数据库、服务端应用程序。服务端程序负责处理HTTP请求、执行业务逻辑、加载和更新数据库数据、查询和填充HTML页面,这个服务端应用就像是一块铁板,笨重且不可拆分,系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外传统的整体风格的架构在进行水平扩展时也只能整个系统扩展,而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务,服务之间相对独立且松耦合,单一功能的改变只需要重新构建部署相应的服务即可。

传统的开发模式在分工时往往以技术为单位,比如UI团队、服务端团队和数据库团队,这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工,不同的服务可以采用不同的技术来实现,一个团队中应该包含开发所需的所有技能,比如用户体验、数据库、项目管理。

传统的软件开发常常以项目为周期,一旦项目开发完成即交付给运维部门,而在微服务架构中,一个团队应该去把控产品的整个生命周期,而不只是开发,这其实也是DevOps的核心理念,所以微服务中的每一个服务都是一个产品,而不是一个项目。

微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能,微服务架构中服务是高内聚的,每个服务都会处理相应的业务,所有的业务逻辑应该尽量在服务内部处理,且服务间的通信尽可能的轻量化,比如使用Restful的方式。

传统的软件开发中经常会使用同一个技术平台来解决所有的问题,而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性,我们可以使用Node.js来开发一个简单的报表页面,使用C++来编写一个实时聊天组件。

微服务架构的引入为多样化持久保存数据提供可能,持久层可以使用传统关系数据库和NoSQL。不同于传统的应用,微服务架构中,我们可以为每个服务选择一个新的适合业务逻辑的数据库系统,比如MongoDB、PostgreSQL。这样做的好处是显而易见的,首先我们可以根据业务类型(读多还是写多等)来决定使用哪种类型的数据库,其次这样可以减小单个数据库的负载。

就James的文章来看,微服务架构主要有以下几个优点:

  1. 每个服务只需要做好一件事,更加专注和简单
  2. 用合适的工具来做合适的事情
  3. 服务之间是松耦合的
  4. 服务的团队之间是相互独立的

James的文章在社区引起了广泛的讨论,近日,Contino公司的CTO Benjamin Wootton在highscalability上撰文表示微服务并没有想象中的那么好,并建议开发者在选用此架构时一定要慎重。Benjamin认为微服务架构时可能会面临下面一些挑战:

  1. 运营开销。更多的服务也就意味着更多的运营,产品团队需要保证所有的相关服务都有完善的监控等基础设施,传统的架构开发者只需要保证一个应用正常运行,而现在却需要保证几十甚至上百道工序高效运转,这是一个艰巨的任务。
  2. DevOps要求。使用微服务架构后,开发团队需要保证一个Tomcat集群可用,保证一个数据库可用,这就意味着团队需要高品质的DevOps和自动化技术。而现在,这样的全栈式人才很少。
  3. 隐式接口。服务和服务之间通过接口来“联系”,当某一个服务更改接口格式时,可能涉及到此接口的所有服务都需要做调整。
  4. 重复劳动。在很多的服务中可能都会使用到同一个功能,而这一功能点没有足够大到提供一个服务的程度,这个时候可能不同的服务团队都会单独开发这一功能,重复的业务逻辑,这违背了良好的软件工程中的很多原则。
  5. 分布式系统的复杂性。微服务通过REST API或消息来将不同的服务联系起来,这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等,而面对如此多的微服务都需要分布式时,整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
  6. 事务、异步、测试面临挑战。跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案,而现在看起来,这些技术并没有成熟。

每一种架构都有其优缺点,当然微服务也包括在内。我们需要根据项目业务和团队情况来选择合适的架构,微服务才刚刚开始发展,这也是顺应PaaS、持续交付、DevOps等新技术理念下的产物,期待微服务架构能得到更广泛的应用。关于微服务,如果您有新的见解,欢迎与我们分享。


感谢杨赛对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

理念 by 宋 琨

微服务架构迎合了简单就是美的现代人审美观,他不只是一种架构,更是一种理念,涉及到团队分工、开发者职责等。赞一个.

这东西新鲜吗? by chen zhong

这不就是分布式吗?有什么区别?

Re: 理念 by 肖 文棣

像淘宝现在搞的去中心化,实际上就是微服务。我觉得是趋势。

Benjamin的质疑每条都是我想说的 by 预 流

这个架构有实际的例子吗?

微服务架构面临的挑战 by Wong Peter

1、2和3应该不是问题
4可以通过内/外部开源的方式解决
5和6是大问题。不过使用到微服务时,通常系统已经非常庞大了,也早就在使用类似的架构了。微服务其实就是把这些架构和思想用一个名词统一完善起来。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT