技改之路:从SOA到微服务

转自CIO之家

SOA是什么

技改之路:从SOA到微服务_第1张图片

服务导向式架构(SOA)是集成多个较大组件(一般是应用)的一种机制,它们将整体构成一个彼此协作的套件。一般来说,每个组件会从始至终执行一块完整的业务逻辑,通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的,但这并非SOA架构模式的要求。尽管没有严格要求,SOA一般使用某种集中式管理,比如审查委员会、主架构师或架构委员会来严格定义每个系统组件应当做什么,如何执行。相同类型的功能可能会按需在多个组件中分别定义与记录,而每个组件所使用的语言与工具集有可能是集中确定与统一的,也可能不是。SOA可能使用任何类型的SDLC、组织架构或符合这种管理的开发模型;敏捷、瀑布、看板管理或者一些组合形式都是可用而不违反SOA原则的。

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

微服务是什么

技改之路:从SOA到微服务_第2张图片

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

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

技改之路:从SOA到微服务_第3张图片

一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。

技改之路:从SOA到微服务_第4张图片
技改之路:从SOA到微服务_第5张图片
技改之路:从SOA到微服务_第6张图片
技改之路:从SOA到微服务_第7张图片
技改之路:从SOA到微服务_第8张图片
技改之路:从SOA到微服务_第9张图片
技改之路:从SOA到微服务_第10张图片
技改之路:从SOA到微服务_第11张图片
技改之路:从SOA到微服务_第12张图片
技改之路:从SOA到微服务_第13张图片
技改之路:从SOA到微服务_第14张图片

技改之路:从SOA到微服务_第15张图片
技改之路:从SOA到微服务_第16张图片
技改之路:从SOA到微服务_第17张图片
技改之路:从SOA到微服务_第18张图片
技改之路:从SOA到微服务_第19张图片
技改之路:从SOA到微服务_第20张图片
技改之路:从SOA到微服务_第21张图片
技改之路:从SOA到微服务_第22张图片

技改之路:从SOA到微服务_第23张图片
技改之路:从SOA到微服务_第24张图片
技改之路:从SOA到微服务_第25张图片
技改之路:从SOA到微服务_第26张图片

技改之路:从SOA到微服务_第27张图片

(作者:张辉清)

微服务有很多优势,但是仅靠微服务不能解决企业IT中的所有问题。例如,微服务需要去除ESB,但是现实的IT系统中,大量的应用和服务是基于ESB而不是微服务。集成现有的系统,需要一些集成总线。实际情况是,微服务和其它企业架构并存。

你可能感兴趣的:(技改之路:从SOA到微服务)