不得不说的五个关系

“在企业IT的服务化转型中,不仅仅只是单个系统的改造,往往是多个系统群的整体转型,则需要考虑和历史遗留以及生态环境的关系。”

0 导入

在本系列文章中我们讲到,微服务架构改造存在潜在的风险和困难,要想成功落地实施,至少需要做好几个方面的前提准备:微服务拆分和演进的方法体系、DevOps生产线体系、微服务治理的框架、分布式服务一致性解决方案。

行文至此,已经重点讨论了其中的两个关键前提:微服务拆分和演进的方法、微服务治理的框架。对于DevOps生产线,是个非常宏大的话题,已自成生态,按下不表;而对于分布式服务一致性解决方案,则是一个技术难题,坦白讲,还需要更多的积累和实践,才能更从容和优雅的跟大家分享。在本系列文章中,暂不展开。

需要注意的是,我们在谈论的不是某一个系统的微服务化改造,而是整个企业IT或者某个领域的整体转型,比如网络运营支撑系统OSS的整体服务化转型。需要考虑OSS的历史遗留、生态环境等,有几个关系问题,我觉得尤为重要,需要厘清。

1 和能力开放平台的关系

相对公司级能力开放平台而言,MSB承担能力网关的作用;相对后端服务而言,MSB承担服务和能力开放管理平台的作用。OSS通过MSB提供本域的能力,并将能力对接到公司级能力开放平台,供公司其他域应用使用。

对于OSS域内部而言,将能力开放和微服务管控结合在一起落地实施,主要考虑到能力开放的功能要求和微服务管控框架中的API网关功能有较大重叠,可结合在一起建设。

2 和数据共享平台的关系

直接基于4+1源系统进行读写API的封装、数据共享出口,并接入到ESB/MSB对外,API调用、数据共享的出入口:统一从ESB/MSB出口,由ESB/MSB统一对外。

数据互联中心定位调整:

1. 长期:逐渐淡化数据共享的定位,长期将演进为大数据应用中心、OSS数据挖掘中心,从各4+1系统抽取数据,主要支持分析性应用,近期重点支撑智能研判系统,远期可基于此开展AI应用创新尝试;

2. 近期:由于4+1系统服务化改造和API封装需要一定的建设周期,近期内可将前期已经接入数据的存量API接口进行优化规范,接入MSB,先行对外输出,体现能力。原则上不再大规模新增接入各类数据用于数据共享。

需要强调的是,在很多场合提到的“数据共享平台”,其实主要是局限在“性能数据、信令数据”,其实只是其中的“性能服务中心”,只是一个局部的中心而已。对于性能和信令等数据,其实是应该数据集中,并通过API封装对外服务的,大批量的数据共享对数据安全是个严峻的挑战。

3 和ESB的关系

ESB目前以数据集成的消息更新通知为主,也有部分同步查询等服务集成。ESB是中心化架构,容易成为瓶颈,长期将演进到MSB微服务管控平台。

ESB下线分为两个阶段:

1. 服务集成迁移:针对目前同步查询等服务集成进行重构,将业务微服务化,先行迁移接入MSB中;

2. 数据集成迁移:采取两种策略,对于部分数据共享,如资源数据同步等,需要审视有无可能通过相应的微服务化API方式代替,避免大量的数据搬迁;保留部分必须通过数据同步共享的集成方式,迁移割接到MSB,此时需要ESB中关于数据集成共享的管控能力(如数据地图、订阅发布、接口监控等)迁移到MSB中。

4 内外部关系

由于OSS系统群由多个不同的集成商外包开发,在和某一个系统集成商沟通的时候,往往会谈到“系统内部的访问不经过网关,外部的访问需要经过网关”,什么是外部,什么是内部?其他厂家的调用是否都是外部?

内部外部不应该按照厂家的边界划分的。未来OSS应该是One Open OSS。公共技术服务、OSS 4+1系统业务服务统一向MSB注册服务。

内部外部的定义关系如下:

1.外部应用或服务:未注册到MSB平台的应用或服务。一种情况是前后端分离,后端服务纳入MSB管理,前端应用如手机APP/WEB UI应用等也可以是微服务形式,但不注册到MSB,部署在网关之外,对后端服务访问统一通过MSB;另一种情况是指外部门应用、自研应用、未开展服务化改造的遗留系统等。

2.内部服务:注册到MSB平台的服务。内部服务之间的调用不需要经过网关,直接调用,通过自定义熔断器实现流量控制和鉴权。内部服务没有UI界面。

5 局部和整体的关系

MSB的技术目标:

1. OSS微服务治理框架:实现对OSS域微服务的统一管理,为OSS域系统微服务改造提供统一的微服务注册发现和管控;

2. SaaS层服务和API的统一管理和开放共享:对外共享OSS通用技术服务、业务服务和数据服务,为服务访问提供安全认证功能,加强对服务访问的管控。

MSB的 业务目标:

1. 快速响应业务需求和变化:通过服务能力的复用和组合,支撑前端应用的快速开发实现,不重复造轮子;

2. 支撑业务创新、自研等。

对于微服务平台的定位,还是需要调整一下。即是共享服务的统一管理,也是OSS统一的微服务治理框架。从长期目标看,如果各个系统还是需要自己部署和维护一套微服务治理的组件,则需要重复建设(完整的微服务治理框架,还是非常复杂的),而且也无法做到端到端的服务链跟踪(部分在各系统内部,部分在MSB,产生服务调用链割裂现象)。所以从长远目标看,还是需要各个系统内部的微服务都能统一接入MSB,实现OSS域内微服务的统一管理。

因此,微服务治理的最终目标,还是希望所有系统都实现前后端分离,所有的微服务都下沉到MSB平台来统一管理,各系统内部不再部署微服务治理框架。

OSS整体的微服务转型,需要分步骤的迭代开展:

1. 单体应用阶段:UI+业务功能+数据访问+DB作为一个单体应用来部署;

2. 微服务化阶段:实现前端后端分离,在这个阶段应用进行业务逻辑拆分,并进行微服务化改造,部分复杂应用内部可以暂时引入部分自己的微服务治理组件,管理仅在应用内部使用的微服务,治理组件和开发框架选型需要遵循MSB的统一要求;

3. 服务能力共享阶段:逐步识别出哪些服务是可以对外共享能力,并将把服务对接到MSB,不需要对外共享的服务暂时仍然由内部的微服务治理组件管理。

4. 微服务统一管理阶段:将各个应用间的微服务组件统一管理。更好的实现服务链路跟踪,统一割接接入MSB平台。

小结:OSS的整体服务化转型,不是某单个系统的事情,需要照顾到历史现状和周边系统的关系。欢迎留言探讨。

本期嘉宾

本期嘉宾 | 段新 中国移动广东公司OSS架构组组长,集团公司OSS架构规划的主要参与者,江湖人称段老师、老段、段公子。具备丰富的运营商OSS大型系统建设、架构规划、技术架构转型改造经验。其在OSS架构管控方面的成果被国际标准组织认可,受邀TM Forum交流分享。

你可能还喜欢

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180608G229U800?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券