组件化与服务化软件架构在中小企业中的建设

董长青　邓程鹏　任女尔

摘要：随着互联网企业的日益发展，软件研发的智能化也得到了进一步提升。但在传统的中小型IT企业中，技术框架比较单一、固定，软件项目研发的复用程度低、研发效率慢，互联网架构知识体系相对庞杂。针对中小企业的转型发展，结合互联网架构的思路，提出组件化与服务化的软件架构体系，支撑中小企业的技术转型，助力软件技术的积累与快速研发交付高质量软件。

关键词：高效研发；组件化；服务化；技术转型

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2018）18-0217-03

1引言

在传统的中小企业中，常用的技术框架如单体J2EE技术框架，往往为了快速交付而造成软件质量低下的情况；同时，为了对应频繁变化的需求、不同开发人员采取了不同的策略解决问题导致代码风格不统一、运维困难；而运维人员由开发人员监管，或运维人员监管多个项目，导致问题定位、质量风险等问题加剧；企业方则为了赚取更大的利益，不注重软件技术的积累与复用，导致重复开发、资源浪费。相比大型的互联网企业，研发、运维体系及技术架构相对适应能力更强，也便于不断衍生新的业务发展，极大地促进了企业的发展进程。分析先进的解决方案，都离不开软件资产管理、组件化研发与服务化研发，但中小企业在实践过程中往往存在技术跨度大、人员投入成本高、收益见效慢、评估困难等问题。那么针对中小企业制定转型思路，并实施步骤的梳理和验证，建立有效的评估模型至关重要【1】。

2 技术架构分析与设计

技术架构包含技术框架、软件工具、通用组件及软件开发方法学。而java的技术框架体系在当前的中小企业中市场占有率较高，依据J2EE技术做技术架构具有一定的代表性，思路和方法可以迁移至C#等项目研发中。

2.1互联网技术架构

互联网技术架构离不开云计算、大数据、微服务、DevOps。其中云计算从IaaS基础设施即服务、PaaS平台即服务、SaaS软件即服务，诠释了以计算资源为基础的一切服务化思想【2】；大数据通过业务数据或采集数据的不断积累，深度发掘潜在知识并进行预测，从而辅助企业决策、信息再建等；微服务作为应对多变的业务扩展需求及并发扩展需求而逐步演进出来的技术框架，技术体系完善，具有非常好的适应能力；Devops作为研发、运维与测试一体化构建的自动化管理方案【3】，体现了“一切自动化”的思想，并且在企业中逐步推广，与微服务的复杂运维体系相辅相成，极大地促进了软件研发质量管理和效率管理【4】。

以电商云平台作为互联网架构的典型案例，基于服务化的思想，从底层构建IaaSAPI平台，进行资源的统一调配管理；上层以平台即服务的模式、用容器技术将平台资源以服务模式完成对外支持【5】；最终针对用户业务将软件均形成微服务，以SaaS模式提供出来；在辅助管理方面，结合用户中心、配置中心、流程中心、監控中心等支撑平台扩展和业务发展【6】。

2.2传统中小企业技术架构转型问题

传统中小企业面临的客户往往也较小，因此用户量小、开发人员动态调增、开发周期小等特点作为主要特点，为了能够最快的软件技术变现，对技术积累不够重视；但是随着软件越做越大、越做越成熟，企业则面临技术转型问题。

但单纯对标互联网企业架构，技术人员水平要求高、短期内开发成本和运维成本明显增加、碰到问题无法及时解决，因此并不是明智的决策。比如，原本的部署只需用tomcat中间件即可，即使负载量增长也可以采用集群部署方式解决；但是采用微服务，tomcat内置不方便开发，分布式一致性问题、解耦问题难以控制，原本2分钟部署的应用，确需要几天时间部署整体微服务环境，然后进行应用部署，成本是几十甚至上百倍。

2.3技术架构设计思路

在解决技术架构转型中的问题过程中，需对准目标方案，然后选择合适的路线。针对解决代码复用率的问题，可以进行组件化研发方式；针对研发效率问题，可以提升框架的易用性和智能化研发进行改进，同时可以辅助自动化工具；针对运维并发问题，可以采用服务化的思想进行调整。针对不同的技术转型阶段，应当合理调整目标。

在每一项技术选型及技术落地过程中，分析投入学习成本和产出节约工作量，以及分析除节约工作量之外的效益，如质量提升后的效益、并发升级的效益等。正确的评估效益有助于落地实施。

同时要注重知识储备与人员培养。人员培养过程也是解决问题的过程，应对不同的业务场景和技能攻坚问题，逐步将人员按照合理的岗位进行划分，如运维与开发分离等。在人员数量有限的情况下，可以采用临岗互备的原则，确保知识体系与技能体系构建过程中，人员岗位能够匹配上。

对标、评估与人员储备，属于三项基本工作。针对中小型企业技术转型，前期目标以快速研发高质量软件为核心目标，中期以构建领域型复用产品为目标，后期以高精尖技术体系为目标进行。

3 组件化与服务化软件架构

组件化架构注重软件代码层复用，服务化架构更注重运行层的复用。

3.1组件化架构

在组件化架构中，主要服务于前期和中期目标。首先针对框架进行规范化建设，选择合适的平台，再补充通用性组件。通用组件包括技术组件和业务组件两部分，技术组件进行了常用的工具类组件封装，尽可能将基于组件的业务实现变得简单，并且保证研发的统一性，便于后期运维；业务组件基于汽车行业的业务体系进行拆分而来，也便于进一步进行研发集成。常用的技术组件包括：工作流引擎、邮件发送、word导出、Excel导入导出、文件上传下载、日志、国际化、系统管理等。

技术组件一方面能够提升单一功能的研发效率，原本50行的代码经过组件封装后可以用20行实现；另一方面能够统一技术，各项目组采用的技术不同，导致没有分享和交流，最终不能有效的复用，同一功能在不同项目组研发可能用1小时或3天都是可能的，甚至是无法解决的技术问题；此外，通过一段时间的使用，组件趋于成熟，避免了相同问题反复调试，大大减少潜在bug。

业务组件的梳理有两种方式，一种根据新项目逐步生成，另一种是梳理旧项目，后者成本更高，见效更慢，短期内无法有效的形成生产力。因此两种方式可以综合考虑，一方面在研发模式上进行改进，另一方面结合旧项目尽可能地抽取新项目使用到的新组件。研发模式如下所示：

考虑将研发模式结合组件化研发进行。在软件设计之后，将要研发的内容与既有组件进行匹配筛选，部分直接可用、部分修改可用、部分全新研发。每次新项目都能生成对应的内容。

在旧项目中梳理业务，可以采用梳理业务架构图的形式，以产品线为单位，结合项目变更情况、项目模块类似情况、模块功能发展趋势，构建业务架构图，从业务角度描述可复用性，如图所示，进一步辅助业务组件的积累和构建。

业务架构图中，复用程度不同，用不同的颜色来标示，方便后续演进；该部分内容由对产品非常熟悉的项目组完成。

3.2服务化架构

组件化架构重点解决复用问题，也就是快速研发高质量软件的问题；服务化架构则针对逐步扩展的大型软件进行的，可以解决并发、扩展等问题。以邮件为例，将发送邮件封装成技术组件、形成接口，那么可以非常方便地调用开发特定业务；但是当整个业务系统的并发性要求逐步提升，单点的邮件登录无法支撑该问题，那么必须进行有效分布式部署方案；传统的分布式是将整个项目多节点部署，而服务化可以将邮件启动为独立运行的服务，当邮件服务无法支撑并发时，可以将邮件服务部署成集群。这种方式更加灵活和便捷，但是也就意味着1个应用被拆分的较为零散，运维复杂度成倍增加。因此服务化架构要到公司产品发展至一定阶段时再执行，并且针对特定复杂产品执行。

最终架构建设确定整体方案后启动建设，对大部分中小型企业，首先进行组件化，然后针对特定产品实施服务化；对于单一产品的中小企业，随着产品规模扩大，也可以直接转型到服务化。

4 架构建设步骤

架构建设步骤主要有：基础平台建设，框架改进与统一，技术组件实施，中间件实施，标准规范构建，工具实施，微服务逐步实施，其中技术组件、工具类、中间件、标准规范可以同步逐步完善。以Java体系的技术架构而言，可以按照如下实施。

（1）基础平台建设：构建以Maven为组件驱动式研发模式的基础平台，包括maven仓库、gitlab代码平台、技术共享信息发布网站。Maven将单一的J2EE应用拆分为父工程与子模块的形式，然后模块和组件可以发布到maven仓库中，可以采用nexus进行构建。

（2）框架改进与统一：按照公司常用框架及问题进行统一改进，如可以规范采用ssm（SpringMVC+Spring+Mybatis）的方式，集成如Jmetrics代码性能检测、Druid数据库连接池sql性能检测、XSS拦截跨站脚本攻击、权限管理等；因前端复用率较低，进行前后端分离，能够更进一步提升软件复用率、并且方便后期扩展微服务模式。

（3）技术组件实施：完成日志、系统管理、邮件等工具类的封装，可以针对性的梳理既有项目提供多种方式。如导出excel，可以采用拼接文档、模板导出等不同方式。

（4）中间件实施：针对redis、memcached、ES等中间件，可以采用共享服务器部署+封装组件的方式，极大的降低开发难度。如redis在服务器上部署之后，开发人员用maven引用组件，就可以直接进行业务缓存；不需要担心运维、部署、接口调研等问题。

（5）标准规范实施：针对框架、组件的使用和实施，应当安排专有人员进行规范的制定与发布、执行监督与反馈收集工作。针对项目繁忙的情况，该方式能够大幅度提升实施成果的推进。项目组没有很好的了解组件应用不充分导致的沟通成本过高、浪费，相对于规范实施与监督的成本要高很多。

（6）工具实施：按照“一切自动化”的思路执行，先执行jenkins，以持续集成为主要，逐步集成sonar技术债务、docker平台等。然后从开发、测试环境逐步过渡到生产环境。

（7）微服务实施：针对特定产品线，进行微服务实施，首先针对框架进行springcloud改进升级，然后将特定无状态的功能转成服务，构建注册、熔断等服务机制，进步一步再实施监控体系。当单微服务构建完成之后，逐步扩展成产品线的微服务化。

5 成果评估模型

成果评估模型决定着整体技术转型过程中的投入、成效是否达成目标。总体评估基于人力成本的投入产出分析，附加技术债务、代码提交次数、运维工作量比例等工作综合评估。对于新项目，先进行项目工作总量的预估x人天，然后在使用框架、组件、工具过程中，沟通学习成本为y，技术解决消耗为z，那么节约工作量为x-y-z，均以人天为单位。同时，跟踪在测试过程中的问题规避情况，如历史系统安全测试修改人天数为m，采用新框架为n，则节约人天数为m-n人天。在旧项目改造中，可以评估单月运维量在改造前后的工作量。

模型在每个企业中应有自己的变更，包括对于质量的提升效益占比、并发性提升对产品推广的效益占比等，都应该进行特定方案的评估模型建立，从而确保实施方案收到足够的认可。

6 总结

以中小企业为架构技术转型为核心，对标互联网架构，围绕组件化、服务化中常见的问题和建设步骤进行系统性规划与实施，能够大幅度提升中小企業技术竞争力。目前，该方案已经在多家中小型企业技术转型构建成功，提升企业研发效率和技术实力明显，为传统架构与互联网架构打通了一条中间方案。

参考文献：

[1] 杨波谷.IT应用对接业务需求，打造企业核心竞争力[J].数字通信世界，2017（11）.

[2] 张春波，汪军陆.云计算技术及应用[J].信息与电脑（理论版），2018（07）.

[3] 周振兴.基于Docker和持续交付的项目管理系统设计与实现[D].大连理工大学，2016.

[4] 洪华军，吴建波，冷文浩.一种基于微服务架构的业务系统设计与实现[J].计算机与数字工程，2018（1）.

[5] 霍跃华，刘银龙.物流大数据分析平台架构及关键技术研究[J].信息技术与信息化，2016（9）.

[6] 胡宇航.“互联网+”结合云计算在传统行业中的应用[J].科技创新与应用，2018（6）.