首页 运维杂谈Microservices VS. SOA,傻傻分不清楚?

Microservices VS. SOA,傻傻分不清楚?

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

编者按:微服务的出现又掀起了一波新的技术热潮,很多人将微服务简单地理解为服务的分隔,于是提出了质疑:这和之前的SOA有什么区别?本文带你找到答案。

Microservices

.SOA

以下为译文:

什么是微服务?

微服务是一种架构设计模式。在微服务架构中,业务逻辑被分解为一系列小的、松耦合的、分布式组件,组合起来形成大型的应用。每个组件都被称为一个微服务,每个微服务负责一个任务或功能。每个微服务可能被其它一个或多个微服务调用,来执行特定的任务,比如用一种统一的方式来处理搜索、图片展示,或其它需要在应用的不同场景下开发或维护多个版本的情况。

使用微服务架构还能形成一种机制来提高新手的生产率,减少新功能推向市场的时间。每个微服务有一个有边界的代码库,以及关联的工具集;开发者不需要了解整个大型的复杂系统就能上手,只需要知道与其微服务相关的部分就好。

微服务可以被很快开发出来,因为他们可以使用手边最适合的语言和工具集,不需要担心应用其它组件的技术选型,也不用担心其他开发者对这些语言和工具是否了解。

为了充分发挥小团队轻便灵活的特点,团队需要有自治权,他们要快速做决定,并且屏蔽外部的监管。为了达到这个目的,整个工作组应该包含了从产品管理到发布和运营的所有相关人员。由于微服务组件是松耦合的,通过API进行通信,对于大部分决定来说,高度的自治权并不影响整个应用的功能。只要微服务向外开发了自己的API,并能被API调用执行对应的功能,整个系统就能运行良好。

由于一个微服务架构中有这么多独立的组件,在一个弹性的网络环境(比如公有云或私有云)中使用现代的DevOps方式,成为了保证整个系统在大多数情况下稳定运行的重要保证。尤其是在很多情况下,健康和负载的自动监控,以及附加实例的自动部署变得至关重要了。

什么是SOA?

SOA(Service Oriented Architecture)是一种集成多个组件(通常是粒度更大的应用)的方式,他们组合起来可以形成一个彼此协作的系统。每个组件专门从头到尾地执行一个完整的业务逻辑,通常涉及多个特定的任务和功能共同完成一个更大的动作。组件是松耦合的,但这不是必要条件。

虽然没有严格的需求,但SOA是典型的集中式管理:一个审核委员会,一个首席架构师或架构委员,严格定义了系统每个组件应该做什么,以及如何去做。如果组件使用的语言和工具集不是集中定义和统一的话,同样类型的功能可能会被分开定义或写在多个组件中。SOA对软件生命周期管理(SDLC)的模式和组织架构都没有严格的限制,开发模式方面:敏捷(agile),瀑布(waterfall),看板(kanban),或者几种模式的组合,都不违背SOA的原则。

而且,虽然DevOps和云计算等新技术对于SOA很有用,但由于这种系统的组件数量不多,所以并不是本质需求。但是这些系统中一些更大的组件可能会相当复杂,自动化非常困难,甚至是不切实际的。

比如,自动化部署成功的标准可能是100%地通过一系列自动化测试。这保证了现有的功能在新的版本中依然正常工作,而新的功能达到预期的目标。随着功能的交互越来越多,现有功能的某些方面,很可能会被看起来并不相关的开发工作意外打散。

而且,一些测试可能会由于环境或网络问题失败。比如,如果100个测试的失败率是5%,失败的时间比率是1%,并不会影响正常的发布。但如果测试的数量成千上万,相同的比例产生的影响就不容小觑了。因此,就算候选发布版本并没有问题,也经常会在失败在不满足部署条件上。

直接对比:以电商网站为例

下面以一个电商网站为例,来对比SOA和微服务架构。电商网站通常有很多功能模块,基本的模块包括:产品目录,用户账户,购物车等。

一个基于SOA技术的开发团队,通常会将这个网站按业务逻辑拆分为几个分别的应用,然后集成到一起。

比如,整个购物车及其所有功能会被放到一个应用中,负责这个应用开发的团队中,每个人都要对整个购物车的业务了如指掌才行。应用内的代码要实现诸如产品展示,从购物车中添加和删除条目,库存查询,送货处理,计税处理,账单处理,展示更新,以及将最后的订单详情发给用户等功能。在购物车应用内的产品展示,与产品目录应用中的产品实现的功能非常类似,但代码由于分属2个应用,由不同的团队维护,可能完全不同。类似的功能却要维护两份完全不同的代码显然并不合理,而且在大型应用中很可能造成不一致的问题。

而基于微服务架构的团队,会将购物车拆分为更小的面向任务的服务,比如:一个计税服务,一个添加/删除条目的服务,一个送货服务,一个账单服务,以及一个形成最终订单的服务。购物车还会用到一些通用服务,比如:产品展示服务,产品图片展示服务,库存查询服务,用户支付选择服务,以及邮件服务。这些通用的代码会被封装为服务,不管是『购物车』,『产品目录』还是『用户账户』可以使用调用这些服务。

Microservices VS. SOA

假设公司决定通过一个第三方为产品的图片加上license,那么图片的地址都要更改,浏览的数据统计也要被加到应用中。在SOA架构中,这个更改会同时影响到产品目录应用和购物车应用。两个应用都要重新测试,才能被部署,如果其中一个应用的更新不能进入部署,就会影响整个应用的更新部署。就算部署成功了,很显然新的图片服务机制比原来要慢了,可能会成为瓶颈。

大家意识到这个问题后,可能会通过部署更多实例的方法来解决,当然产品展示应用和购物车应用都要增加实例(如果有合适的监控和部署方案的话,这个过程可能是自动的)。这意味着整个应用都要被扩展了,虽然很多功能并不需要额外的资源。

而在微服务的世界中,这种情况只需要更新一个服务:产品图片展示服务。在不影响系统其它部分的条件下,修改、测试和部署一个服务是很快的。而且某个服务出现了瓶颈的话,可以独立地扩展,避免了资源的浪费。

以上假设都基于你要发布一个大型的电子商务网站,用户量很大,并且分布地域很广。如果你只卖一个产品,并且顾客限定为美国地区使用UPS的顾客,许多电商网站的基础设施和复杂度都不在你的考虑范围内。

你依然要跟踪用户信息,提供购物车和结账功能,而且要有一个页面展示产品信息,图片,以及一部分用户评论,但是所有这些功能都要比大型电商简单很多。不需要考虑产品目录,送货选项,添加或删除商品,以及所有其它多种商品的电商需要考虑的问题。

这种情况下,使用SOA的架构更适合,因为每个组件的复杂度都降低到了可管理的程度,而且实现这种网站所需的开发人员数量也不多,免去了要靠小微型的独立团队来扩展规模的问题。

类似但是不同

所以微服务和SOA有很多类似之处:两种系统都由松耦合的分布式组件构成。但是两种架构背后的意图是非常不同的:SOA意在集成应用,而且使用集中管理模式来确保应用间的交互。而微服务意在更高效地部署新功能和扩展开发团队,并且组织的非集权化,代码重用和自动化。

总结如下:

Microservices VS. SOA

原文出处:灵雀云

英文链接:https://www.voxxed.com/blog/2016/01/microservices-versus-soa-practice/

本文链接:http://www.yunweipai.com/7744.html

网友评论comments

发表评论

邮箱地址不会被公开。

暂无评论

Copyright © 2012-2021 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部