中台|啥都复用不了，还谈什么狗屁中台( 二 )

学习可复用组件的成本!
别人造的轮子有时候很难了解它内部的构造和逻辑，就要去学习别人造轮子的设计和逻辑，这个本身是存在学习成本的，如果对方的设计和实现与自己的思路存在出入的时候，又会非常的别扭。
扩展可复用组件的成本！
前人造的轮子都是用在他当时的那个场景或者业务中，当这个轮子切换到新的场景和业务中的时候，你会发现100%的可复用基本上是没有的，这时候就牵扯到对于这个轮子的扩展以适用新的业务，先不说这个扩展改造是所有者执行还是使用者执行（后面有一个章节专门讨论组织的逻辑），扩展总是有成本。
修改可复用组件的成本！
有时候组件的抽象能力不够，无法扩展，或者扩展的时间成本太高，或者组件所有者不愿意支持，复用者可能采用直接拿过来修改的情况。修改的成本是一个层面，但把时间拉长来看，组件修改后就和原组件分化了，未来双方的新功能也无法相互复用了。
2. 复用是有级别的一般情况，复用的成本会因为复用的组件的内容不同，所在组织的关系亲密，它的成本是不一样的。比如只是复用一段程序，就相当简单，如果复用一个系统功能就很困难；如果复用同一个团队的组件就相当简单，如果跨团队跨组织的复用就会变得困难，所以复用也是有级别的，为了更好的理解我把复用分成了一下5个级别。

级别越低，粒度越小，复用的范围越广，但价值体现较低；级别越高，粒度越大，复用的价值越高，但复用范围也比较局限。所以站在业务和价值角度上，都是先从最高的层次上去复用。只有上层无法实现复用，我们才会逐步向下层去寻找。但是有时候站在技术角度，我们习惯在低层次上去复用，因为这里最接近自己的工作，粒度越小，技术上越可控。
回到本节开始的问题，B系统的功能要复用A系统的功能，这个复用级别是最高的，如果能复用那会极大减少工作量降低成本，但这个级别的复用难度也是最大的，特别是异构系统，就几乎没有可能了。
3. 复用是有粒度的影响复用达成时间的因素很多，这些因素叠加起来可能导致复用所消耗的时间更多。因此对于一些时间特别敏感、由其决定生死的业务，在可复用组件未成熟，或者可复用组件支持团队的支持力度不够时，可以不考虑复用。
不复用的情况就是我们通常讲的烟囱系统，现在大环境的论调是烟囱系统不好，其在一个业务成熟的公司里确实不好。但是烟囱系统在业务早期变化大，快速野蛮生长时,由于不需要考虑复用,没有太多的条条框框限制,提供了高效的开发效率支持，为业务的存活做了重要贡献。

Gartner 在研究报告里提出了宏服务、小服务和微服务的粒度划分：

宏服务——一种传统的 Web 服务，支持将功能封装于单体应用内。宏服务不支持独立部署或扩展，它们只能部署为单体应用的一部分，而且它们不需要微服务基础架构。
小服务——就服务粒度范围而言，小服务是一种粗粒度、松散耦合、支持独立部署的应用组件。小服务需要微服务基础架构。
微服务——微服务处于粒度范围的远端，是一种可独立部署的组件，能够支持单个应用功能的实施。微服务可直接部署到微服务运行时环境中，也往往具备专用数据存储区。微服务需要微服务基础架构。

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