微服务架构在气象业务系统建设之经验分享

昨天分享了《中台战略与气象业务系统建设之经验分享》，今天继续分享一下【微服务】架构在气象业务系统建设之中所遇到的问题。【微服务】的软件架构在当下非常流行，尤其是JAVA技术栈中有非常多的【微服务】框架可供开发者选择。大名鼎鼎的SpringBoot、SpringCloud都成为企业级【微服务】架构落地的经典架构。还有Dubbo这个阿里巴巴开源的分布式服务化治理框架，除了阿里自己采用，京东、当当、携程、去哪儿等一些企业都在使用。【微服务】架构的十大好处：1）易拆分；2）易理解；3）易扩展；4）易修改；5）易替换；6）易部署；7）易伸缩；8）易恢复；9）易链接；10）易交付。

看到这些确实很诱人，我们气象部门的业务系统开发，也越来越青睐于【微服务】架构这种更加便捷的软件架构风格。更进一步讲，它与中台战略转型解决烟囱林立、数据孤岛、重复建设问题是一脉相承的，当前很多互联网公司和传统大型企业的数字化转型的IT实践都是采用【微服务】架构。采用【微服务】的好处不再赘述，聊聊我通过这一年多时间采用【微服务】架构进行气象业务系统开发的一点经验。不是技术分享，更多的是管理经验的总结和分享。在这个过程中我发现，【微服务】架构在气象业务系统建设中的可实施性存在太多的不确定性。

【甲乙双方对微服务缺乏理解和实践经验】

当前气象业务系统建设主要采用软件外包来实现。【微服务】架构对于IT开发人员来说虽然不算陌生，并且在我们制定的后端JAVA语言中有比较成熟的开发框架供开发人员选择，但是到真正的实践中我们才发现外包公司懂得【微服务】架构下开发的人少之又少。我们在外包气象业务系统开发时都喜欢选择有气象背景的公司，感觉这样能够更充分理解我们的气象业务，减少沟通成本，但这些公司并不是非常专业的软件外包公司。气象部门的需求单位由于专业受限，很少真正去关心互联网公司的先进IT架构，这就造成了甲乙双方面对【微服务】架构的开发常常陷入一头雾水的怪圈中，不知道应该怎么去将我们的气象业务需求拆分成一个个“高内聚、低耦合”的【微服务】模块，更谈不上享受【微服务】开发的快速、灵活和可独立部署的各种优势了。很多气象公司仍旧采用的是传统的单体应用开发模式，开发思路依然保持着需求对接、需求设计、原型开发，然后跟甲方申请一堆的服务器，自己搭建开发和测试环境，进行代码编写、循环测试，最后交付上线，整个流程下来就是一个单体应用架构，和【微服务】架构的开发模式相去甚远。在实施过程中，我们为了让【微服务】模块拆分的更合理也做了很多努力，尝试着用最原始的方法梳理业务流程、划分业务模块，然后进行小的功能模块拆分，依葫芦画瓢，最后发现拆分出来的模块就是一个“四不像”，自己都很难说清楚这样拆分是否合理。在不断的思考中，我觉得【微服务】架构落地实施的过程中缺少这样一个关键角色，叫架构师。每个项目都应该有一个或多个架构师。对于甲方我们可以称作业务架构师，乙方就是软件架构师，有既懂业务也懂IT的可以同一个人承担。架构师这个角色非常重要，他是落地实施【微服务】架构的关键角色。虽然在项目组织过程中甲方会要求各乙方公司要配备一个项目经理、一个技术经理（架构师），可实际实施过程中基本上都是两个角色一肩挑，另外一般小规模开发公司根本就没有架构师。

【微服务架构开发缺少方法论支撑】

这个问题是紧接着上一个问题来讲的，在【微服务】实践过程中根本不知道怎么进行【微服务】拆分，或者只知其一不知其二，想着尽量往“微”上拆或者按照功能拆，其实这都是不对的。究其原因还是大家对【微服务】架构缺少实战经验，同时也没有一个方法论来进行支撑。我也一直在思考这个问题，直到发现DDD(Domian Driven Design)，才明白要做好【微服务】架构的软件开发，领域驱动设计这个环节必不可少。（还有其他一些方法与DDD的实现目标是一致的）他是【微服务】实践的方法支撑，能够教会我们如何从业务角度出发进行业务驱动模型设计（请参阅《气象业务驱动模型设计》一文，MODM：Meteorological Operations Driven Model）、采用“通用语言”交流并进行【微服务】拆分。【微服务】并不是拆的越细越好，拆的太细会造成系统开发复杂度大增而无法上线，也不是拆的越粗越好，粒度太大会造成模块之间存在太多的耦合性，让系统变得死板、厚重难以适应前端的快速变化。认识到这一点，我发现我们在实施【微服务】架构开发过程中就会存在太多的不确定性，因为我们甲方以及乙方公司都很少有人懂DDD的设计方法，那【微服务】的拆分就更难实现了。

【业务需求边界划分不清晰】

这是我在管理气象业务系统建设时遇到的又一个比较难解决的问题，业务需求边界不清晰，沟通协调成本大增。从我们气象部门业务软件项目的组织来看，一个需求单位内部都会划分为好几个小项目并且由不同的公司进行开发，这原本考虑的是让任务拆解，减小项目风险，可在开发过程中发现要交叉复用的业务需求很多，要进行集约化开发就需要重新设计业务功能并划分出业务需求边界。这个问题之所以出现，其实是由于在项目立项之初就没有考虑清楚应该如何进行业务平台的开发，缺少全局设计和整体设计。问题已经出现了，我在处理这样的软件开发项目中也尝试去解决或者减少一些需求边界划分不清晰的影响。常用的方法是组织一个需求单位所有的软件开发公司，一起梳理并找出分项目中的公共需求，然后根据工作量分给每家公司，同时要求一家公司完成的模块要能够让另外一家公司调用，以减少重复开发。虽然按照这样的方法执行了，可后续会带来很多关于合同、验收、接口、任务扯皮等等一系列问题。从设计之初就要想清楚，业务需求的边界问题，设计出标准规范的业务边界，会让多个公司进行联合开发更容易。

【需求方缺少对业务清晰理解的领域专家】

气象业务需求转换成让IT公司充分理解的技术实现路径并按照需求完成开发是我们进气象业务系统开发的目的，可往往是需求设计的挺好，软件的实现很糟。我经常在软件项目实施开发过程中遇到这样的窘境。我们用了充足的时间进行需求采集、需求分析并形成需求说明书，还要进行需求评审。但是根据最终的业务软件开发状况来说，依然不能开发出我们很满意的系统，我考虑问题的根源在于缺少一个对本单位业务清晰理解的领域专家，并能够将气象业务需求准确传达给公司的开发人员来完成开发。针对乙方公司来说，在意的是甲方提出的功能需求，而不是甲方的气象业务，并且这是两个领域，气象和IT的结合，中间少了一个关键连接。一般在气象业务软件开发中会由气象部门的需求方配置一个技术联系人，这个角色就应该是领域专家，但实际上这个技术联系人只承担了技术联系的职能，没有承担起领域专家的职能，并且让气象部门需求方的技术联系人承担过多的项目管理职责，内部驱动力也不足，管理权限也有限。

今天就聊到这儿，关于【微服务】在气象业务系统建设过程中的技术问题，我们今后再细说。您是否正在实施【微服务】架构下的气象业务系统开发呢？欢迎留下您宝贵意见，共同分享经验！