微服务与业务中台的思考-后记

之前我写过一篇《微服务与中台的思考》，在该篇文章中我主要强调的是微服务带来的自治问题，从而引申出来的是组织架构及管理的匹配。貌似很多朋友对此不以为然，而且有朋友说我的认识比较片面。后来我思考了一下，我发现我文章中写的太直接了当了，缺少铺垫和必要的阐述，本来事情有2层，我一下子说的是底下那层，但是别人一般关注的是表面那层，所以引出了一些对微服务及中台的不同的看法就很自然了。

1. 业务中台的表层概念：
   借用昨天沟通的朋友给我的意见，给业务中台用一句话描述出来：就是业务中台的关键是将各个业务中的有共性的业务场景总结出来，形成共性的能力，将该能力放在业务中台内，而前端业务可以通过配置或少量代码进行快速的开发，从而匹配商业社会的快速发展的需求。

换成我自己的语言，我会用一个更浅显易懂的方法来描述：传统做软件就是从0做起，从0%做到100%；后来有了框架（例如SSH），那新做一个项目相当于从30%做到100%；现在业务中台就是将尽量多共性的功能放到中台，则新做一个项目相当于从80%做到100%。需要新开发、配置的工作越少，效率越高，则这样才能满足当今商业客户的快速需求变化。

使用量化的方法去描述问题，别人（即使不懂技术的人）会更容易理解你的理念。

现在的业务中台，基本是以微服务的形式去落地的。

2. 业务中台及微服务的深层理念：
   业务中台的是共性的业务场景或者业务功能独立抽离及实现，独立实现放到一个个微服务中，所以带来两个特点：
   1）每个微服务可以被上层应用（例如手机客户端的APP）进行快速配置来调用形成新的业务；
   2）每个微服务独立开发及部署；

对于第一个特点，关键是将共性业务的能力独立出来，被上层调用，则是否使用微服务这种形式，并不是关键，例如单体系统中代码上有个类库集合了所有这些共性业务的功能，一样可以实现这个理念；

对于第二个特点，微服务独立开发及部署；有两个好处，一个是把整个系统这样一个复杂的大问题分成一个个简单的小问题，一个个简单的小问题开发、维护起来会更简单；另一个好处是独立部署，借用现在的虚拟化、容器技术，可以快速部署及做负载均衡；举例就是例如双11晚上12点，下单支付的人特别多，就是使用支付网关这个微服务的人特别多，则可以单独给支付网关这个微服务快速增加服务器，来阶段性的、局域性的给系统以扩容支撑。

对于第二个特点，会引来一些影响（这个就是我在上文《微服务与中台的思考》中主要提到的问题）：例如每个微服务需要单独的团队服务开发和维护（不是必须，但是最佳实践）；例如微服务之间的关系是网状的，维护较复杂。引申到组织管理，就是首先需要形成多个小团队，分别管理每个微服务；而小团队之间的沟通协调会比较复杂；这是典型的技术方案带来的组织架构及管理的变化，很多人并没有意识到这个深层次的问题。我意识到这个问题，是因为我曾经需要对于是否引入微服务架构到自己的产品进行决策，让我意识到，考虑技术架构，不仅仅是技术问题、业务场景问题、客户问题，还是团队自身的组织管理问题（我曾经将团队从产品研发的架构转换成以项目为主产品为辅的组织架构，所以在这块考虑比较多）。

引入一个新的架构，可以很简单，也可能很复杂，甚至因为组织架构不匹配导致引入的失败。而现在很多公司、团队都喜欢追捧新技术、新架构（理解这种跟风，往往是风投关注的），例如业务中台、数据中台；新技术本身并没有错，但是我们做企业，目的不是搞新技术，而是帮助客户达成商业目的从而促使自身的盈利；同一个目的，有不同的手段（这是我常讲的道与术），所以是否需要这些新技术，需要考虑自身的情况、客户的情况、业务场景等因素，因为有可能使用一个很挫很旧的技术方案，但是更快、成本更低就能实现目的，而使用一个新技术，却更慢、成本更高，而且副作用更大，都是很有可能的。作为一个决策者，不能盲目跟风，需要真正懂得新技术后面的理念，然后根据自身情况进行适配在进行决策。风投在投的时候的确关注技术方向，但是实际上一个企业的基本面还是其盈利水平决定的。