APP下载

面向企业协作服务的新型业务架构探索与实践*

2017-08-31程宝平王兆辉汪胜陈进利

电信工程技术与标准化 2017年8期
关键词:运维部署架构

程宝平,王兆辉,汪胜,陈进利

(中移(杭州)信息技术有限公司/中国移动杭州研发中心,杭州 310000)

面向企业协作服务的新型业务架构探索与实践*

程宝平,王兆辉,汪胜,陈进利

(中移(杭州)信息技术有限公司/中国移动杭州研发中心,杭州 310000)

系统基于自研自容器微服务架构,通过自定义轻量化协议实现终端两省一低(省电、省流量、低功耗)平台三高一低(高扩展性、高负载、高可用、低资源消耗),以办公型即时通讯录、企业融合通信、企业办公协同为基础,实现办公的移动化、平台化、社交化、业务化,全面提升员工效率,充分释放组织潜能。

智慧政企;融合通信;协作办公;微服务

1 企业协作服务架构现状

1.1 现状概述

传统企业协作服务多采用单体式架构设计,应用核心是业务逻辑,由定义服务、域、对象和事件等模块完成,围绕着核心的是与外界交互的适配器,适配器包括数据库访问组件、生产和处理消息的组件,以及提供API或者UI访问支持的Web模块等。

虽然采用的多是模块化逻辑,模块之间虚拟隔离,但是最终它还是会打包并部署为单体式应用。例如许多Java应用会被打包为WAR格式,部署在Tomcat或者Jetty上,而另外一些Java应用会被打包成自包含的JAR格式,同样,Rails和Node.js会被打包成层级目录。

这种传统的应用开发风格被大规模应用在企业平台开发,因为IDE和其它工具都擅长开发一个简单应用,这类应用也很易于调试,只需要简单运行此应用,用简单UI测试方式就可以完成端到端测试。单体式应用也易于部署,只需要把打包应用拷贝到服务器端,通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。

1.2 存在的问题

传统单体式系统架构在用户体验、研发运维、可靠性等多方面存在问题,随着系统不断迭代,开发和运维团队的效率将受到极大挑战。

(1)从用户体验角度,应用的发布与更新都会造成业务的中断和暂停,导致用户会有间歇性的服务不可用体验。

(2)从研发运维角度,简单的应用会随着时间推移逐渐变大,敏捷开发和部署举步维艰,复杂而巨大的单体式应用也不利于持续性开发,如今,SaaS应用常态就是每天会改变很多次,而这对于单体式应用模式非常困难。另外,这种变化带来的影响并没有很好的被理解,所以不得不做很多手工测试,持续部署也会很艰难。

(3)从性能的可扩容的角度,当单体应用的某一个模块遇到性能瓶颈需要扩容,会导致整体应用的扩展和扩容,导致了不必要系统资源的浪费。

(4)从稳定性的角度,因为所有模块都运行在一个进程中,任何一个模块中的一个bug,比如内存泄露,将会有可能弄垮整个进程。除此之外,因为所有应用实例都是唯一的,这个bug将会影响到整个应用的可靠性。

2 企业协作服务新架构方案

2.1 方案概述

单体服务架构通过服务内模块化实现模块间低耦合,模块内高内聚,单体服务架构通常表现为六边形架构,一个典型的企业办公类产品架构通常设计如图1所示。

随着时间的推移,应用系统会变得越来越庞大,没有人能够对系统整体了如指掌,同时敏捷迭代和部署变得举步维艰,修正bug和正确的添加新功能变的非常困难和耗时。

以云企信为例:未进行架构改造之前,核心服务代码超过2G,编译部署一次需要5 min以上,应用运行对服务器配置要求高,扩展困难,可靠性原来越差。

在我们实际的研发中也发现,业务在往复杂化发展,用户的需求越来越个性化,甚至各个省的客户由于地域差异也会出现需求冲突。

解决好如上问题成为架构师最大的挑战,因此在新架构设计的时候创新性引入了“分而治之”的思想,对业务进行独立分拆,相似业务独立为一个小服务,即方兴未艾的微服务理念,服务之间互联互通,自由伸缩,系统具备良好扩展性。

同时,引入扩展性良好的业务协议,降低终端的资源消耗,降低终端开发和平台开发的沟通难度。

对系统整体而言,可以保障系统在未来可见的生命周期内满足用户增长、运营活动的支撑要求。

2.2 架构总体设计

如图2所示,系统架构设计方面在企业服务行业首创地引入分层设计原则,自上而下分为负载均衡层、连接层、服务层、数据层4层, 4层架构清晰明了,逻辑清晰,每一层均独立可扩展。

负载均衡层摒弃原F5硬负载均衡方案,采用软负载的方式降低运维成本,提高系统扩展性。

连接层负责所有终端、管理系统的接入,通过移动终端长连接保持、前后端分离设计的管理系统、自研轻量化业务协议,实现终端良好用户体验。

服务层是整体系统的核心,为系统的业务承载层,服务之间可自由通信,通过引入服务治理概念,实现服务间自动负载均衡,有效提高服务的扩展性和灵活性;同时,服务层采用嵌入式监控,对服务的健康状况进行实时监控。

数据层为系统的文件、数据、缓存、通知——订阅、消息的集中存储,方便运维进行管理。

2.3 关键技术特征

2.3.1 微服务架构设计与服务治理

图1 企业服务平台六边形架构体系

图2 企业服务平台新型架构体系

在本系统的设计实现过程中,微服务更多的是一种理念,代表灵活可自由拼装的软件设计,通常一类业务会组装成一个独立的服务,微服务架构有以下几个好处。

(1)通过分解巨大单体式应用为多个服务方法解决了复杂性问题,在功能不变的情况下,应用被分解为多个可管理的分支或服务,每个服务都有一个用RPC——或者消息驱动API定义清楚的边界,微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。

(2)这种架构使得每个服务都可以有专门开发团队来开发,开发者可以自由选择开发技术,提供API服务。当然,许多公司试图避免混乱,只提供某些技术选择。然后,这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。

(3)微服务架构模式是每个微服务独立的部署,开发者不再需要协调其它服务部署对本服务的影响,这种改变可以加快部署速度,UI团队可以采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。

(4)微服务架构模式使得每个服务独立扩展,你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。

微服务给我们的系统开发带来诸多好处的同时,也给系统的运维带来了诸多挑战,诸如服务治理、服务保障、服务间通信保障、服务监控等系统运行问题,考虑到尽量降低系统运行风险,在系统设计之初便引入了服务治理与嵌入式监控,以保障服务的高可用和良好扩展性。

图3 企业服务平台服务治理示意图

图4 序列化反序列化性能对比图

如图3所示,服务治理是为了解决服务间调度及自动化运维问题而设计的,通过引入统一服务注册中心,所有服务启动时完成注册中心登记才可标记服务成功启动,服务调用方通过订阅该服务名称来获知服务的变更信息(服务启动、停止、扩展)。

2.3.2 接入层透明代理设计

本系统架构设计中,创新性设计了透明代理机制,即统一所有终端连接管理到一个connector服务,该服务负责终端的链接管理、服务调用和消息推送,这为研发过程和用户体验带来了如下好处。

(1)在研发过程中,终端与平台服务间之间进行协议协商,连接器对协议过程不关心。

(2)在平台业务上下架过程,连接器服务会一直保持正常运行,终端不会有掉线的体验。

(3)运维可随时发布、更新服务,不需要选择服务器闲时。

2.3.3 自研轻量化协议

行业内领先的协议设计,基于protobuffer3.0,自研全套业务协议,实现信令私有化,实现终端通信的两省一低(省电、省流量、低功耗),同时保障系统的通信安全,与其它通用协议自研轻量化协议具备如下优势。

(1)性能高,基于二进制序列化框架,提高序列化性能,经过实际测试,反序列化性能提升4倍(xmpp:0.86μs V pb:0.22μs),序列化性能提升20倍(xmpp:2.37μs VS pb:0.12μs),如图4所示。

(2)流量低,通过协议本身的合理制定和流量压缩技术,可以实现80%的流量降低,实际对比测试数据如图5所示。

图5 流量消耗对比图

(3)开发效率高,自研协议代码生成器,开发者只需要关心业务本身如何设计。

(4)兼容性好,是完美的前后兼容方案。向前兼容,模块A升级后,模块B可以正常识别A发出的新版本协议,此时,新增的属性会被忽略;向后兼容,模块B升级后,能够正常识别A发出的老版本协议,由于老版本没有新增的属性,在扩充协议时,一般设置为非必填或定义默认值。

3 开发实践

移动互联网时代,一个新的业务点从思路产生到产品上线,软件的研发效率是十分重要的指标,对于一个大型软件系统来说,如何能够在既有体系架构下,以最低的侵入性将一个全新的业务无缝构建出来,是这套架构需要重点解决的问题。

3.1 基础架构体系分析

我们通常将新型企业服务平台分成两大部分:基础平台+扩展模块,基础平台中运转着系统核心业务,同时也是扩展业务得以热插拔的基石,如图6所示。

图6 企业服务平台基础平台+扩展平台架构体系

在基础平台中,我们根据企业服务的特性,梳理出连接器、用户中心、消息网关、推送服务、短信中心、配置中心、日志分析、服务调度等核心服务,这些服务所承载的业务需求较为单一和固定,很少有需求变更的情况。作为基础平台,需要在架构之初,设计出供扩展模块调用的Base-API,Base-API的特点是业务无关性,例如用户中心提供的获取用户所在企业的API,因其业务无关性可被多个扩展模块所调用。

在传统企业服务平台中,新的业务需求产生后,通常的思路是在既有服务模块上增加代码来实现。在新型企业服务平台中,我们的做法是全新构建一个微服务,以扩展模块的形态,通过服务发现,与基础平台融合在一起。同时在基础平台的服务调度中心,可以快速上架、下架这些扩展模块,实现服务的热插拔,业务灵活性大大提高。

3.2 扩展服务研发实践

在新型企业服务平台架构体系下,一个新的扩展服务通常按照图7所示的流程进行研发推进。

(1) 详细设计:在新型企业服务平台架构下,通常详细设计阶段由平台研发人员主导推进,主要内容包括技术实现流程设计、交互协议定义、数据库设计等。交互协议主要有终端交互协议和内部服务交互协议,针对移动办公的业务特性,我们制定了基于Protobuf+Service接口模式的协议模型,该技术模型提供了较好的前向兼容性与后向兼容性,大大提升了版本升级迭代的便利性。

(2) 代码生成:在大型企业服务平台中,如何保障众多微服务模块的技术框架一致性是重要的课题,因此我们设计了一套代码生成器。根据详细设计阶段定义的PB协议,代码生成器可生成出除了业务逻辑外的标准化代码框架。包括自容器调试运行框架、接口代理点、全环境配置等,开发人员基于这套基础框架,增加业务逻辑代码,能够在很短的时间内完成一个微服务模块的开发。

(3) 联调测试:扩展模块的内聚性很强,扩展模块之间通常没有耦合性,与Base Platform之间也仅通过Base-API进行单向数据交互。同时,通过服务透明代理,Base Platform中的连接器为客户端和扩展模块之间架起了一座无形的桥梁,在联调测试过程中,客户端研发人员通过调用扩展模块提供的终端PB接口,完成端到端的业务流程。

图7 扩展服务研发流程

(4) 质量管控:随着扩展模块不断增多,服务上线的敏捷性要求也越来越高。由于模块间耦合性很低,新增一个扩展模块对于系统整体质量不会造成影响,因此我们的质量管控的重点也就落在扩展模块自身上。我们在模块代码框架上限制了模块必须通过静态代码扫描和单元测试,否则无法编译通过,也就无法进入集成测试。实践表明,经过这两项流程,测试一次性通过率提升到了80%以上。

(5) 服务发布:在统一框架下研发微服务,对于需求迭代效率、问题追踪、团队人员协作等都有极大的提升,但随之也带来运维的难度。由于微服务模块非常多,依靠运维人员通过脚本部署很容易造成人为失误,在生产环境留下隐患。我们在Base Platform中设计了服务治理中心,融入DevOps的思想,提供可视化运维界面,实现服务的部署与编排。同时建立一套服务&服务器的健康度监测模型,进行实时监控与预警。

4 总结与展望

面向企业协作服务的新型业务架构通过自研核心技术,提供的不仅仅是一种解决方案,而是一种创新的开发方式,这种方式将产品、研发、测试、运维、质量保障等各个角色通过架构设计机密的结合在一起,把研发角色通过架构设计渗透到各个角色分工中,形成技术主导的DevOps系统研发模式,保障了良好的分工协作。

同时,良好架构设计让开发人员能够把更多的精力放在业务本身,花更多的精力去设计业务,产出相关设计文档,从重编码向重设计转型,实现研发人员定位、价值的提升。

当然,新架构需要经过实践的检验,不断完善,才能不断成熟,目前新架构已经应用与小溪云通信、政企云企信、集团版小移人家、山东云企信、政企企业网关等诸多项目中,满足PaaS、IaaS等多种部署方式。

以云企信为例,新架构投产之后,相比较老系统而言提升显著,新架构在商用成熟度快速提高。

(1)服务器资源使用降低一半,整体平台可完全部署在低配虚拟云主机上,不依赖任何专用硬件设备。

(2) 系统稳定性大大提高,基本实现无人值守式运维。

(3) 开发迭代效率显著提高,双周迭代内完成需求数量提高30%。

(4)版本周期内,客户反馈bug数量下降60%,运营效率大大提高。

在不断商用过程中,遵循以用促研的原则,满足基本产品需求之外,未来新型业务架构将在服务健康度监测、自动化运维、分布式消息跟踪、灰度发布等方面不断完善,达到更高的商用标准,打造行业知名的企业协作服务架构技术体系。

Exploration and practice of new business architecture for enterprise collaborative service

CHENG Bao-ping, WANG Zhao-hui, WANG Sheng, CHEN Jin-li
(China Mobile (Hangzhou) Information Technology Co., Ltd./ China Mobile Hangzhou R & D Center, Hangzhou 310000, China)

The system is based on self-porting micro-service architecture, to implements a terminal with low-power, and a platform with high-scalability, high-load, high-availability, low resource consumption, to officetype instant messaging, corporate integration communications, enterprise office collaboration as the basis, to achieve office mobility, platform, socialization, business, and comprehensively enhance staff efficiency, fully release organizational potential.

wisdom government and enterprise; integration communication; cooperative office; micro service

TP311

A

1008-5599(2017)08-00015-06

2017-07-03

* 中国移动集团级一类科技创新成果,原成果名称为《企业融合通信产品(云企信、企业飞信、小移人家、工作机)》。

猜你喜欢

运维部署架构
基于FPGA的RNN硬件加速架构
一种基于Kubernetes的Web应用部署与配置系统
晋城:安排部署 统防统治
功能架构在电子电气架构开发中的应用和实践
部署
运维技术研发决策中ITSS运维成熟度模型应用初探
风电运维困局
杂乱无章的光伏运维 百亿市场如何成长
WebGIS架构下的地理信息系统构建研究
部署“萨德”意欲何为?