一、前言

二、系统复用为什么难？

• 小服务——就服务粒度范围而言，小服务是一种粗粒度、松散耦合、支持独立部署的应用组件。小服务需要微服务基础架构。

如果我们想对已存在系统的能力进行复用，可以采用宏服务模式进行，宏服务的模式适合做系统的集成和治理。我们对于新的业务和项目，刚开始建议采用小服务的方式进行业务领域的拆分，不建议拆分的过细，这个小服务能满足该需求的基本抽象即可。从适中的粒度开始，服务的粒度一定是业务推进的过程中不断演化的，创新业务推动服务的粒度向更细的粒度裂变，而业务成熟稳定后，又推动服务向粗粒度方向聚合。站在复用的角度，优先级是宏服务>小服务>微服务，当然难度反之。

所以复用要根据自身团队发展情况，业务实际需要灵活把握，也要根据公司的发展阶段，逐步的实现复用，总体来说复用的优先级技术层面复用优先于业务层面复用，团队内的复用优先于团队间的复用，项目级复用优先于产品级复用。

技术栈的统一，只能让我们做到LV1和LV2层级的复用能力，再往上走就涉及到功能层面和业务层面了，而这更接近老板的视角了。所以实现更高层次的复用是每个技术领导人的追求，也是发挥自身专业能力的舞台。

但在这个环节我们往往会出现大问题，就是不能根据实际情况因地制宜，架构体系的弹性很大，没有严格的标准，只有根据实际情况的平衡，平衡是考验技术领导人的架构艺术，不要小瞧了这个能力。很多大厂的牛人去小企业做架构，太多失败的案例，不是架构不好，是没有用对地方。

1）对于小团队而言，统一架构体系，单体应用一样很美。

我们一贯的常识就是，越是独立的，没有太多耦合关系的组件越容易复用，过去烟囱似的单体系统难以复用就是模块和系统本身耦合太深而造成复用改造的成本很大。这个理论是对的，但我认为不全面，完全去除耦合是不现实的，只是耦合的深浅和范围是需要管理的，如果复用组件的使用者一样耦合在同样一个环境中，其实也是可以复用的。这就像A系统要复用B系统的模块其实是很困难的，因为耦合的环境不一样，依赖的基础不同；但是A系统内要复用自身系统的某模块却非常容易，因为依赖环境是一样的。所以，小团队如果在代码层级能够统一成一个应用，然后通过插件化、代码级的组件化对业务模块进行抽象和管理，单体系统依然是很美的。

我在七八年前带一个小型互联网团队，自己花了两三个月时间写了一套基于JFinal（当时刚开始推出的小众框架，现在已经非常流行了）插件化的脚手架系统作为我们团队所有业务开发的载体，这么多年过去了，这个系统依然在健壮的运行，业务也在不断持续的开发着。我们实施的泛微最新一代的OA系统，如此庞大的系统，通过部署结构来看，其实也是一个大单体应用。所以，不是单体系统不好，只是当它太大以后，我们没有能力管理好它而已。

2）有一定规模的技术组织，构建统一平台底座。

复用的成本以及难度往往都是组织规模扩大，尤其分化后才迅速提升的。在一个多组织中实现组件的复用需要建立统一的标准，也不要完全去除依赖，而是尽可能依赖单一，大家都依赖这个单一的东西，这个依赖对复用的影响就会降低，所以一定规模的技术组织，要通过构建统一的平台底座，将共享组件沉淀在平台底座上，让不同的业务共同依赖同一套底层的环境，通过平台底座的共享能力，实现各垂直业务的横向交流和协同。这种模式特别适合软件产品研发的企业，构建在厚实的平台之上的产品研发，既高效又善于组合和扩展，产品的边界不会因为系统的隔离而变的僵化。而且构建平台底座既适合单体架构的应用也适合分布式的微服务架构，平台底座其实一个组织有规划的复用的体系建设。下图是笔者团队建设的平台体系，后台引擎由架构团队主要负责建设，业务组件（属于中台范畴）由各研发团队根据业务领域分别负责构建，供做参考。

3）企业级的复用体系--中台架构

中台的广义上的定义：企业级能力复用平台。

虽然我们的一体化平台涉及到中台服务部分，但是作为研发企业，我们的中台架构和服务是面向客户去交付的，帮助甲方客户构建中台能力。一般情况我们所说的中台，不是厂商的中台解决方案，而是一个互联网企业或者一个传统企业为了满足自身数字化转型的需要而构建的中台体系，它是面向企业运营的中台体系而不是面向项目交付的中台服务。

广义上的中台范围是非常大的，涵盖了企业运营的方方面面，而我们更关注的是企业中台的载体即数字化运营中台。企业首先通过信息化建设，将企业内在业务从线下搬到了线上，这个阶段我们构建了一个个的单体系统，这些系统集成都不容易，复用几乎就更没可能。最终导致大量的重复开发建设，同时还带了更大的系统治理的成本。

进入数字化时代，甚至是智能化时代，面对激烈的市场竞争，企业降本增效的需求愈发迫切，更好的复用，更敏捷的建设是企业迫切的愿望，中台体系的提出，是顺应这个时代的产物，所以企业关注中台，尝试中台是对的，至于为什么会失败，后面的文章再去探讨。

对于一个有技术开发能力的企业，比如互联网企业，科技企业等，中台的复用能力不要极端的追求新建，虽然这样比较简单，但对企业来说着实浪费，如上图所示，首先单体应用架构向业务中台架构演变，能利用则利用，能改造就尽量不要新建，能沉淀就尽量沉淀。

被复用的组件需要进行修改定制时，我们需要组件的维护方提供支持，此时就需要相应的沟通协调成本。若组件提供方与组件使用方没有任何利益关系，甚至于其利益是冲突的，那么组件提供方则缺乏动力为使用者提供支持，甚至于拒绝提供服务。这时候沟通协调成本将会特别的大。（本文提到的那位研发负责人其实很大程度上也面临这个问题，协调不动组件方修改，自己改又太有难度，与其不如自己造一个轮子了）

这个问题实际上不是一个软件技术问题，这涉及到组织架构的设计。因此要降低沟通协调成本，则需要更高一级的领导设计调整组件提供方与使用方之间的关系，使其达到利益相关、一致。如下图所示，每个人在自己管辖的范围之内都相对比较容易复用和协作（对应颜色的横向箭头），而一旦超出了这个范围，复用和协同的难度和成本就会急剧增加。

重温下康威定律：

已经五十多年的康威定律依然是指导我们做系统设计和企业架构的重要定律，它诠释了系统架构和组织架构的对应关系，其实这非常容易理解，任何事情都是有人去执行的，人的组织结构决定了系统的架构设计，一个分散型的组织很难有高度统一的架构，也注定难以复用。当然一个集权化的组织，复用和协作的成本就很低，相反组织的活性会降低，自主性和创新性不足。

老板最重要的任务其实是通过设计组织的结构，来匹配做事情的逻辑，最终实现自己想要的效果，否则在一个人、物、事不匹配的环境里，只有一腔的热血、殷切的希望和愤怒的咆哮也是无济于事，这便是规律的不可违背性。

正如阿里巴巴实施中台战略，CTO行癫（张建峰）亲自挂帅负责中台事业群，负责中台战略的推进。同时作为当时整个集团的CTO，在各事业部横向推行中台架构体系又有谁不配合呢，可见阿里中台战略的执行力有多强，这也是为什么阿里的中台能够成为行业的标杆，这与其组织的设计是分不开的。

最后总结一下，复用是老板的合理需求，是技术领导人的核心职责，是所有技术人的全局意识。但复用的达成，不是老板的念念不忘，不是技术领导人的行政要求，也不是所有技术人的满腹牢骚，它需要一个体系的设计，一个组织的支撑，一个相互信任的团队文化，一个不断完善的过程。任重而道远，让我们励志前行！