一、起因：野蛮生长
近十年，中国互联网发展的速度越来越快，互联网科技颠覆了越来越多的传统行业，我们的衣食住行随着互联网科技的进步，发生了翻天覆地的变化。在这个大潮中，越来越多新兴的公司如雨后春笋般的冒了出来，他们的业务增长非常快，公司规模也越来越大。这得益于中国经济的高速增长和互联网的快速发展。
![]()
弊端一：自我繁衍
在公司快速的发展过程中，往往会出现这样一个链条。新增一块业务 —> 招聘一位高级技术人员 —> 围绕这位同事组建一只技术团队 —> 该业务基本由这只团队负责。然后就形成了一个闭环。当需要跟其他业务进行交互时，经常是技术负责人之间自行决定。（我曾经经历过一个项目，同样一个业务接口，同时提供 RPC，HTTP，MQ 等多种方式，为了给不同的项目提供基础服务）。
弊端二：管控壁垒
随着业务规模的快速发展，这个团队很快的形成了一个部门，团队决策者通常会从自身利益考量，希望尽量减少对外部门的依赖，无论是技术选型，规范建立，组件选取，运行环境都能够自行掌控。（在这里讲一个笑话，在一家公司怎么成为中层领导呢？很简单，招聘足够多的下属就可以了）。
![]()
弊端三：断崖效应
当这样的技术氛围一旦形成，单个员工对单个项目的影响就会变的非常巨大。一个产品经常会因为一两个核心员工的离职难以为继，最后不得不重新开发新的产品。
![]()
弊端四：资源浪费
当每个团队都在试图构建自己完整的研发流程时。中间的技术研究，产品研发，运维管理就会出现非常多的资源浪费。
![]()
弊端五：难以考核
怎么衡量一个川菜厨师和一个鲁菜厨师谁更优秀？当每个团队都采用不同技术栈，不同的技术组件，不同的维护方式和规范时。已经无法从产出效率来判断一个团队的绩效。KPI 指标也就非常难以设立。
![]()
二、如何破解？
在公司发展初期，为了快速的进行业务拓展，大都不考虑成本投入，运营维护以及技术沉淀等问题。所有的指标导向都是业务的快速发展，尽可能的抢占市场份额，获取足够多的用户数量。
在公司发展到一定阶段后，市场逐渐趋于稳定，先期快速扩展的各种问题会逐步暴露出来。从技术层面来讲，如果可以形成公司级别的统一开发框架，会在实际的生产过程中带来非常大的收益。
三、统一开发框架的优势
3.1 避免重复性技术研究——节约人力成本
让项目组把精力更多的投入到业务中。相信这是大多数技术公司的共识，如果让项目组把精力投入在业务中？就需要在项目组之下构建一个基础的开发架构平台，把技术的共性问题提炼出来，交给这样一个团队负责处理。避免每个项目都独自去解决遇到的各种各样的技术难题，有效的把精力释放出来。
3.2 标准化技术规范——提升产品项目质量
要千人一面，而不要千人千面。采用统一的开发框架（平台）后，在技术栈，技术组件，技术实现方案，甚至在代码规范上就能形成标准化的技术输出模式，标准化带来的最大效果不仅仅开发效率的快速提升，还有产品质量的大幅提升，这是显而易见的。
3.3 进行技术沉淀——提升公司整体技术能力，避免陷入一个人的能力决定一个项目
技术的进步来源于不断的技术积累和沉淀。每个工程师都是站在别人肩膀上完成工作的。以项目为导向的技术团队，一般都会以实现业务需求为最重要的目标，技术只不过是完成业务的一种工具而已。基于此，业务开发团队就不可能把技术积累作为一项重要的工作。当一位核心员工构建了一些基础的平台工具后，往往随着他的离开把之前的技术积累全部丢弃掉，而更严重的情况会导致整个项目的持续运行都成了问题。
当存在公司级别的统一开发框架（平台），项目团队基于该平台进行自身项目的研发，不再需要关注于底层技术实现，只需要关注业务即可。当存在核心同事离职时，平台的研发同事可以对新进入项目的同事进行相关培训，不会导致青黄不接的事情发生。而且，专注于平台的同事为了更好的满足项目组的技术需求，对平台进行不断的改进，从而达到技术积累和沉淀的目标。
3.4 可衡量的研发投入——对研发团队的有效管理和考核
当基于同一开发框架（平台）的标准化技术规范建立起来后，对业务功能的代码实现就可以进行相对有效的评估和考量，可以避免因为技术实现差异而出现的种种问题。这对 KPI 的制定和考核是一个巨大的帮助。
四、统一开发框架（平台）的定位和目标
统一开发框架（平台）定位于技术层面，其主要目的是为统一公司内相关产品研发和项目实施使用的技术架构和开发工具，有效提高统一技术支持力度，形成持续的技术积累手段，提升技术人员的利用率并降低对人员的依赖性，最终提升软件的规模化、流水线式的生产能力。
五、统一开发框架（平台）的建设思路
5.1 基于 Spring Cloud 技术栈
Spring Cloud 在 2017 年一跃成为最流行的微服务开发框架，不是采用了 Spring Cloud 框架就实现了微服务架构，具备了微服务架构的优势。正确的理解是使用 Spring Cloud 框架开发微服务架构的系统，使系统具备微服务架构的优势。下图为选择 Spring Cloud 作为技术栈的原因。
![]()
5.2 部分 SpringCloud 构件的增强
Spring Cloud 提供的基础构建可能无法完全满足业务需求，需要在部分构件之上做二次研发。比如我们在 Zuul 基础之上研发的 API 网关、服务注册发现中心 EurekaPlus 等。
下图为服务注册发现中心 EurekaPlus 的截图，可以手动控制服务注册中心的节点状态，从而支持蓝绿部署。
![]()
5.3 新基础组件产品的研发
除了 Spring Cloud 的基础构件外，我们往往需要开发新的基础组件产品来满足项目组的需求。特别是当前微服务架构大行其道，常常需要基于微服务架构的设计思想来开发新的组件产品，比如我们开发的分布式任务调度框架。采用自动抓取，在线编排的模式，完全契合于 Spring Cloud 技术栈。
下图为分布式任务调度框架原理。执行器在启动时将任务接口注册到分布式数据中心，编排中心从分布式数据中心获取执行器信息进行编排，然后把编排信息保存到数据存储中，调度中心从数据存储中获取信息对执行器进行远程调度。
![]()
六、统一开发框架（平台）团队的运作方式
如何在公司推进统一开发框架（平台）的建设，并不是一件简单的事情。以我个人的经验，从分工和运作方式上来讲，我主要着重把统一开发框架（平台）的工作分成三个部分。
开发示例、技术支持和技术规范。编写完整的开发示例，对很多新接触统一开发框架的同事来说，有一份完成业务开发是非常重要，不仅仅可以指导你如何进行业务代码的编写，同时还能够指导你如何编写出正确、高效的代码。还需要对很多同事进行技术培训与技术支持支持，都是统一开发框架（平台）团队应该完成的工作。
服务运维。统一开发框架（平台）提供了很多公司内部的服务，比如服务注册发现中心、配置中心、监控中心、链路中心、健康监测中心等。这些都需要统一开发框架（平台）团队进行运维。
新组件、新产品的研发。前一章节提到的 API 网关、分布式任务调度框架、服务注册中心 Plus 等。都是统一开发框架（平台）团队的工作范围。
七、过犹不及
虽然建设公司级的统一开发框架（平台）会在实际的生产过程中带来非常大的收益。但未必适用于所有情况，考虑到某些项目产品的特殊性，并不能一概而论。
作者：梁鑫
来源：宜信技术学院
