从SOA到微服务的演进之路.docx
《从SOA到微服务的演进之路.docx》由会员分享,可在线阅读,更多相关《从SOA到微服务的演进之路.docx(5页珍藏版)》请在冰豆网上搜索。
![从SOA到微服务的演进之路.docx](https://file1.bdocx.com/fileroot1/2023-2/2/166f62bb-431c-49d6-a4ce-f6c700707be2/166f62bb-431c-49d6-a4ce-f6c700707be21.gif)
从SOA到微服务的演进之路
从SOA到微服务的演进之路
SOA是什么,服务导向式架构(SOA)是集成多个较大组件(一般是应用)的一种机制,它们将整体构成一个彼此协作的套件。
一般来说,每个组件会从始至终执行一块完整的业务逻辑,通常包括完成整体大action所需的各种具体任务与功能。
组件一般都是松耦合的,但这并非SOA架构模式的要求。
尽管没有严格要求,SOA一般使用某种集中式管理,比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么,如何执行。
相同类型的功能可能会按需在多个组件中分别定义与记录,而每个组件所使用的语言与工具集有可能是集中确定与统一的,也可能不是。
SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型;敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。
此外,现代化的DevOps和云部署对SOA当然很有效,在这种系统中缩减组件数量并非必需。
但在这些系统中,就算在最好的情况下,一些较大的组件也可能太过复杂而难以实现自动化,在最坏的情况下甚至完全无法实现。
微服务是什么
微服务是一种架构设计模式。
在微服务架构中,业务逻辑被拆分成一系列小而松散耦合的分布式组件,共同构成了较大的应用。
每个组件都被称为微服务,而每个微服务都在整体架构中执行着单独的任务,或负责单独的功能。
每个微服务可能会被一个或多个其他微服务调用,以执行较大应用需要完成的具体任务;系统还为任务执行——比如搜索或显示图片任务,或者其他可能需要多次执行的任务提供了统一的解决处理方式,并限制应用内不同地方生成或维护相同功能的多个版本。
使用微服务架构还提供这样一种机制:
增加新加入开发者的生产效率,并减少新功能的推广时长。
每个微服务的代码库与相关工具集都很有限;开发者无需再去了解庞大而复杂的系统,只需理解自己所做的那部分微服务相关子集,便能贡献生产力。
由于无需考虑应用的现有部分使用了什么语言或工具集,或者较大应用的其他开发者是否了解这些语言和工具,只需使用当前任务最趁手的工具,因此微服务开发起来非常迅速。
一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。
微服务有很多优势,但是仅靠微服务不能解决企业IT中的所有问题。
例如,微服务需要去除ESB,但是现实的IT系统中,大量的应用和服务是基于ESB而不是微服务。
集成现有的系统,需要一些集成总线。
实际情况是,微服务和其它企业架构并存。