从SOA到微服务,这是一个迭代的过程

企业动态
选择分布式事务非常麻烦,有时候不得不选择最终一致性来妥协; 还有服务多了,客户调用起来非常的麻烦,所以经常得把多个接口API封装,对外提供一个简单的接口;当然这种基于HTTP的调用远没有原来的在一个进程内的方式效率高。

小明毕业后为了户口,进入了一家大型国企的信息部门工作, 这个国企不差钱, 几十年来随着IT系统的发展, 也与时俱进地兴建了多个信息系统,只不过自家开发的极少, 从外边购买的极多, 虽然信息部也有开发能力, 但是当甲方的感觉是最妙的, 何况出了问题还可以把责任推出去。

在这些系统当中, 小一点儿的有自动化办公系统(OA) , 休假系统,车辆管理系统, 薪水支付系统, 大点儿的有客户关系管理系统, ERP系统 ..... 等等, 可以说是琳琅满目,让人目不暇接,几十年来IT发展的技术,几乎都能在公司的IT环境中找到。

小明的工作之一就是维护现在的IT系统博物馆, 博物馆中大部分都是遗留系统, 能工作,但是非常的老旧。硬件平台, 软件环境,开发语言各部相同,都是异构的。

就说那个休假系统吧,还是用上个世纪流行的Delphi 写的。 还有那个OA系统, 也是上个世纪的ASP,运行在IIS上。 虽然界面丑陋,勉强能用。

也有一点新东西,比如上周上线的那个维修系统不就用了最新的前端技术嘛, 小明也着实激动了一阵,看了两天的React。

有一天有个著名外企的销售来到了小明的公司,请信息部门的老大吃了饭,K了歌。。。好像还搞了些小明这些小兵不知道的秘密活动。

第二天老大给国企老总做了汇报, 过了一段时间, 公司发文了:

为了提升IT效率,打破各个信息孤岛,实现各个信息系统之间的互联互通, 让业务和IT进行对齐, 达到业务敏捷性, 公司经慎重研究决定,邀请xxx公司作为咨询顾问, 从即日起开始实施SOA战略。

小明看了一遍,愣住了,上面的字全都认识, 但连起来就不知道是什么意思, 虚头巴脑的, 唯一确定的是,咨询顾问要来了,要开始什么SOA了。

顾问果然来了, 先给小明他们的信息部门洗了一次脑, 小明的脑海中被各种新式的名词所充斥: SOA, ESB, SCA, BEPL.... 下了课, 小明和同事们讨论了很久, 模模糊糊的明白了要做什么事情。

好像是把这些遗留的异构系统包装成粗粒度的服务, 还是 Web 服务,可以通过Http来访问, 然后呢, 让大家互相调用, 甚至可以把这些服务进行编排,形成一个大的业务流程, 完成更高层次的业务, 听起来挺有意思的。

外企的销售非常精明, 趁势卖了一大批硬件和软件, 他们的技术团队还确实帮着做了一个小的验证系统, 实现了一个业务场景,展示给公司老总看, 老总非常满意: 不错, 我们公司又一次站到了IT技术的前沿!

然后就没有下文了, 领导们似乎忘记了, SOA似乎没有发生过,互联互通呢? 业务敏捷呢?

小明很困惑,周末约着同学张大胖去吃饭。

张大胖在一个互联网公司工作, 主要是做网上约车系统, 用的都是最前沿的技术, 他说: 听起来你们要把这些遗留的异构系统做数据/信息的集成啊, 只是没有做下去而已, 国企嘛可以理解。 你知道我们公司在干什么事儿吗?

小明说:“不会和我们一样吧?”

“完全不同! 我们公司才成立几年啊, 最重要的就是这个约车系统, 当然我们现在发展的很快,这三年以来系统已经快变成一个巨无霸了, 代码已经达到百万行级别, 没人能搞明白了, 代码库非常难于管理, 冲突不断。 系统部署也非常困难, 一点点小改动都需要巨无霸式的整体部署, 你能想象得到吗, 我们系统重启一次得15分钟!”

“我赛, 这么慢? 不可思议,我用过你们的打车软件, 用起来还可以啊?”

“唉, 金玉其外,败絮其中, 你不知道我们每次发布有多痛苦, 但是竞争激烈, 我们还得频繁发布。 所以我们做的事情和你们相反, 不是集成, 而是拆分! 把一个巨无霸变成一些小的组件, 让这些小组件能完全独立的开发, 测试和部署。”

“那你们的开发团队怎么办?” 小明问。

“我们的组织结构也要随着这些小组件来重构啊,你看我们分成了“乘客管理”,“司机管理”,“旅程管理”,“支付管理”等好多组, 每个组只负责他们特定的一块儿功能, 并且每个组里边都有设计,开发,测试,部署等人员,一应俱全, 他们从头到尾全程负责。”

“有意思啊,这些小组件都是独立的,每个组件实例都是一个进程吧, 那这些小组件怎么交互? 难道也是通过我们公司所用的Web service ?”

“不不, 我们不用那重量级的Web service , 什么WSDL, 什么SOAP, 我们统统不用, 我们只用最轻量级的、基于Http 的Restful 来对外提供接口”

小明突然想到一个问题:“你们每个部门负责一个特定功能,那数据怎么办?还用统一的数据库吗?”

“这是个老大难问题,我们得做数据库的拆分啊,唉, 一言难尽。”

小明说 :“可以理解,不过这样以来确实是更加敏捷了。”

大胖说:“这还不是最厉害的,最厉害的是我们能快速的自动化的部署这些小组件,并且能为他们创建很多实例来运行,有一个挂掉了也没关系,别人可以调用那些还在运行的。”

“所以关键点就是这些小组件对外提供的服务是无状态的,对吧?”

“没错”  大胖说, “这一点和你们的SOA是一样的, 对了, 告诉你一个小秘密,我们在生产环境会做一些‘猴子测试’,通过写脚本随机的停掉一些实例,看看我们的系统运行的怎么样”

小明说:“厉害啊,你们都玩的可都是心跳啊。”

“木有办法,只有在生产环境才能发现真正的问题啊”

“难道你们的这种方式没有缺点吗?”

“当然有了, 就拿数据库来说吧, 数据做了分区, 一致性怎么保证啊? 选择分布式事务非常麻烦, 有时候不得不选择最终一致性来妥协;还有服务多了, 客户调用起来非常的麻烦, 所以经常得把多个接口API封装,对外提供一个简单的接口;当然这种基于HTTP的调用远没有原来的在一个进程内的方式效率高。 还有一个要命的问题就是监控,你想想这么多运行的实例, 互相之间有调用关系,一个地方出错了, 怎么追踪啊,很麻烦。”

“不管如何, 你们这种把系统拆分,让一个独立的组织负责独立的部分还是很敏捷啊, 对了,你说的小组件,难道没有一个像SOA这样的高大上名称吗?”

“当然有了, 业界把这种方式叫做微服务! 虽然这个词不能完整的表达我们做的事情。 我现在很期望Martin Flower 给它起个更贴切的名称,就像Dependency Injection 那样, 比之前的IoC强多了。 ”

吃过饭回去的路上,小明心想:天下大势,真是分久必合,合久必分啊, 我们在零散系统的集成, 大胖他们又在搞巨无霸应用的拆分。

相比而言,小明还是羡慕大胖,羡慕他们公司的朝气蓬勃。 他虽然明白自己所在国企的信息系统和大胖做的不一样, 但是暮气沉沉的感觉让人看不到希望, 再这么混下去, 热爱的技术可就真的废了。

过了年,小明已经在国企服务了3年了,顺利的拿到了帝都的户口, 然后毫不迟疑的跳槽到了大胖的公司,去搞微服务去了。

【本文为51CTO专栏作者“刘欣”的原创稿件,转载请通过作者微信公众号coderising获取授权】

戳这里,看该作者更多好文

责任编辑:武晓燕 来源: 51CTO专栏
相关推荐

2015-12-09 11:08:29

微服务SOAESB

2019-08-06 13:37:55

微服务架构数据

2016-08-25 20:55:19

微服务架构发布

2020-04-07 15:12:07

微服务架构数据

2022-09-19 08:07:28

Goweb 程序

2017-07-05 15:09:52

密码token浏览器

2021-05-20 13:22:31

架构运维技术

2022-07-06 19:00:00

微服务框架链路

2022-03-30 08:50:00

服务网格SOA

2019-10-08 11:04:44

SOA微服务架构

2021-08-03 09:07:39

GolangGrpc服务

2023-01-04 11:41:31

微服务SOA架构

2020-12-12 13:50:16

云开发

2021-01-27 13:54:05

开发云原生工具

2022-11-08 08:35:53

架构微服务移动

2021-01-22 17:46:37

微服务开源Web

2021-07-12 05:01:11

云原生软件架构

2019-08-21 17:41:29

操作系统软件设计

2021-03-17 10:51:16

架构运维技术

2016-08-25 21:12:31

微服务架构发布
点赞
收藏

51CTO技术栈公众号