微服务与SOA的实践应用对比

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介:

关于微服务是什么,面向服务的体系结构(SOA)又是什么,两者之间有何关联真是众说纷纭、困惑颇多。很多人都加入了这场讨论,从ThoughtWorks的Martin Fowler到Cap Gemini的Steve Jones全都参与了进来。


微服务是什么?

微服务是一种架构设计模式。在微服务架构中,业务逻辑被拆分成一系列小而松散耦合的分布式组件,共同构成了较大的应用。每个组件都被称为微服务,而每个微服务都在整体架构中执行着单独的任务,或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用,以执行较大应用需要完成的具体任务;系统还为任务执行——比如搜索或显示图片任务,或者其他可能需要多次执行的任务提供了统一的解决处理方式,并限制应用内不同地方生成或维护相同功能的多个版本。


使用微服务架构还提供这样一种机制:增加新加入开发者的生产效率,并减少新功能的推广时长。每个微服务的代码库与相关工具集都很有限;开发者无需再去了解庞大而复杂的系统,只需理解自己所做的那部分微服务相关子集,便能贡献生产力。由于无需考虑应用的现有部分使用了什么语言或工具集,或者较大应用的其他开发者是否了解这些语言和工具,只需使用当前任务最趁手的工具,因此微服务开发起来非常迅速。


为了充分利用速度优势,让小团队开发成为可能,团队需要自主权;他们必须能迅速作出决定,避免过度监管。要想支持这一点,工作团队应当包括所有相关人员,从产品经理到发布运行人员。由于微服务组件是松散耦合并通过API通讯的,各方在大多决定时拥有高度自主权并不会影响应用的整体功能。只要微服务能发布API,并能用这些API执行所需的功能,整体系统就能运作良好。


由于在一个微服务架构中有许多独立的组件,在弹性网络(比如公共或私有云)上使用现代化的DevOps对于确保整体系统在大多数情况下正常运转就显得尤为重要。特别是像与额外实例的自动部署相关联的健康与负载自动监控(为了尽可能减少未充分利用的实例)这样的东西在很多情况下就变得至关重要。


SOA是什么?

服务导向式架构(SOA)是集成多个较大组件(一般是应用)的一种机制,它们将整体构成一个彼此协作的套件。一般来说,每个组件会从始至终执行一块完整的业务逻辑,通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的,但这并非SOA架构模式的要求。


尽管没有严格要求,SOA一般使用某种集中式管理,比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么,如何执行。相同类型的功能可能会按需在多个组件中分别定义与记录,而每个组件所使用的语言与工具集有可能是集中确定与统一的,也可能不是。SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型;敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。


此外,现代化的DevOps和云部署对SOA当然很有效,在这种系统中缩减组件数量并非必需。但在这些系统中,就算在最好的情况下,一些较大的组件也可能太过复杂而难以实现自动化,在最坏的情况下甚至完全无法实现。


举个例子,自动化部署的一个标准可能得需要100%通过一套自动化测试。这将确保现有的功能在新版本中仍旧可用(没有回归),而新功能也按照预期实现。随着功能交互越来越多,看似不相关的开发工作意外破坏现有功能某些方面的可能性有所增加。


此外一些测试可能很敏感,由于坏境或网络因素而出现失败个例。在100个测试案例中,5%的随机测试出现1%的失败率不会对普通发布造成大的阻碍。而在成千上万的测试中,同样的几率可能会造成较大影响,很多时候会造成至少一个随机故障。因此,即便要发布的版本没有什么实际的错误,也会因为无法通过这条标准而无法部署。


直接对比——建立购物车

我们来看一个在线购物网站。这个网站会有一些不同的功能,比如产品目录、用户帐号还有购物车等等。


使用SOA的开发公司一般会将购物网站拆分成主要的业务逻辑组,并将每个部分作为独立应用分别开发,最后集成到一起。


举个例子,整个购物车及其所有功能是由一大群人所开发的一个应用,他们需要了解整个购物车的工作机制,以便能够修改。在这个应用中,是代码负责显示物品、增加或移除购物车商品、查看库存、处理运费选项、处理税率计算、处理汇率、在更改时更新显示并将最终的订单细节发到用户邮箱里(还有其他等等)。用来显示购物车商品的代码包括在购物车应用中,可能与在浏览目录视图中用来显示商品名称的代码截然不同,从而造成需要维护的两套代码相似但不相同,还可能造成大应用UX上的某些不一致。


使用微服务架构的开发公司会将购物车切分成较小的任务导向服务。不再是购物车应用了,而可能是税率计算服务、添加/移除商品服务、运费服务、汇率服务和最终订单撰写服务。购物车功能可能也会用到一些常用的服务——它们会用在购物应用的很多地方,比如显示商品服务、显示产品图片服务、查看库存服务、用户支付偏好服务以及邮件服务。而“购物车”、“产品目录、“用户账户”之间并没有分界,通用代码被封装成各种服务,待需要时用在各种功能中。

图片描述

当公司向中心授权组织请求展示产品时,必须修改展示来源,还得将浏览统计添加到购物应用中。在SOA架构中,产品目录应用和购物车应用必须独立各自更新,以体现变更。


需要对两个应用进行重测试,以确保变更没有影响其他功能,然后再重新部署。如果在这两个有改动的应用中还有其他功能有所变更,这一过程可能会进一步拖延(取决于开发进度的实现情况),而无法发布。一旦重新部署,负责展示的新机制速度可能明显要比旧机制慢,从而成为瓶颈。


延迟会导致客户投诉,然后问题被报告给管理层。有管理者决定要通过向整个产品目录应用与购物车应用部署额外实例,以处理额外的负载,应对延迟问题(如果有适当的监控与部署规则,这可能是自动执行的)。由于整个应用需要扩展,整个过程需要大量的额外处理能力与存储空间,在未执行额外部署的情况下,很多功能可能只能勉强运行。


而在微服务这里,只需进行一项改变——更新产品展示服务。这项服务可以独立进行快速的更改、测试与部署,而不会影响到大系统中的其他部分。此外,一旦发现瓶颈(很可能是通过自动化监控),无需向产品目录功能或者购物车服务所使用的其他服务部署更多实例,就能(可能是自动的)部署这项服务的额外实例,从而限制了支持额外部署所需的资源。


以上所有都是建立在想要发布一个大型在线商店,向各地各类人等售卖各类产品的假设上。如果假设你只想向美国境内的客户贩卖一种商品,并且只使用UPS作为物流的话。大量架构与复杂的在线商店都是没有必要的。


虽然仍需追踪用户信息、提供购物车与结算功能、展示产品信息与图片,甚至一些评论评价,但每一项功能所需都比复杂的在线商店要少得多。产品分类需求、计算不同运费选项的需求、系统处理增加/移除延时差异的需求还有所有其他综合商城所需的功能都不再需要。


在这种情况下,使用SOA将购物车、用户账户与产品展示组件与网站相集成可能要比使用微服务架构(像上面描述的那样有更为细致的组件定义)更有意义。在这种简单的设置中,不仅每个较大的组件被降低到复杂程度可控的范围内,而且实现这类网站所需的开发与其他员工的人数都会很少,无需将小型独立团队进行拓展。


相似却不相同

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。但是两种架构背后的意图是不同的:SOA尝试将应用集成,一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能,快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。


总结:

功能 SOA 微服务
组件大小 大块业务逻辑 单独任务或小块业务逻辑
耦合 通常松耦合 总是松耦合
公司架构 任何类型 小型、专注于功能交叉的团队
管理 着重中央管理 着重分散管理
目标 确保应用能够交互操作 执行新功能,快速拓展开发团队

哪种适合你的公司呢?完全取决于你的选择。


原文链接: Microservices Versus SOA in Practice 

译文转自:http://geek.csdn.net/news/detail/51826

深入阅读:浅析深究什么是SOA?

















本文转自UltraSQL51CTO博客,原文链接:http://blog.51cto.com/ultrasql/1910480 ,如需转载请自行联系原作者




相关文章
|
11天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
28 1
|
15天前
|
监控 持续交付 API
深入理解微服务架构:从设计原则到实践应用
深入理解微服务架构:从设计原则到实践应用
|
22天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
43 5
|
26天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
21天前
|
Kubernetes API Docker
构建高效后端服务:微服务架构的深度实践与优化####
本文深入探讨了微服务架构在现代后端开发中的应用,通过剖析其核心概念、设计原则及实施策略,结合具体案例分析,展示了如何有效提升系统的可扩展性、可靠性和维护性。文章还详细阐述了微服务拆分的方法论、服务间通信的最佳实践、以及容器化与编排工具(如Docker和Kubernetes)的应用技巧,为读者提供了一份全面的微服务架构落地指南。 ####
|
23天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
27天前
|
Go 数据处理 API
Go语言在微服务架构中的应用与优势
本文摘要采用问答形式,以期提供更直接的信息获取方式。 Q1: 为什么选择Go语言进行微服务开发? A1: Go语言的并发模型、简洁的语法和高效的编译速度使其成为微服务架构的理想选择。 Q2: Go语言在微服务架构中有哪些优势? A2: 主要优势包括高性能、高并发处理能力、简洁的代码和强大的标准库。 Q3: 文章将如何展示Go语言在微服务中的应用? A3: 通过对比其他语言和展示Go语言在实际项目中的应用案例,来说明其在微服务架构中的优势。
|
24天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
24天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
|
22天前
|
架构师 中间件 API
微服务和 SOA 的 6 大核心区别,你都知道吗?
本文详解SOA与微服务的六大区别,帮助更好地理解和应用这两种架构,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
微服务和 SOA 的 6 大核心区别,你都知道吗?