技术人员要有慧眼和正见—谈谈对微服务和中台的理解

   微服务、中台思想、区块链是软件行业的热词，这些词汇有一种铺天盖地的感觉，交流时没有涉及到这些似乎难以启齿，但真的懂了这些背后的本质和来龙去脉而不是人云亦云？

   微服务 

  先说微服务，它似乎是一颗新的救命稻草和银弹，不管它是否适用都往上扯。微服务真的是前所未有的新技术新概念？其实不是，微服务就是SOA服务化中的细粒度服务而已，不是啥新技术。在微服务这个热词出现之前，根据实际需要，在系统架构设计中拆分出细粒度的服务是很平常的事情。服务注册服务发现、服务注册中心、服务网关、服务治理、限流熔断等都是很早就有，也不是啥新鲜玩意。

   在架构设计中对系统做适当粒度的拆分(分解)才是关键，不是微服务，当然并不排斥微服务。如何进行架构分解，强烈推荐本人的这篇文章：软件架构分解。如何拿捏好是否"适当"，就是要在考虑系统的业务量和面临的具体痛点、团队结构和人力和所所熟悉的技术栈、上线时间期限、配套的运维体系成熟度等基础上，进行权衡，来对系统进行适当粒度的服务拆分，微服务可能并不适用于实际情况。当然随着容器化的兴起和服务化框架的成熟完善，比较便利微服务的开发部署而已，并不说明微服务就是银弹，在不合适的阶段，过早拆分得过细，反而增加开发、运维成本和数据不一致的可能性。

   spring cloud这些所谓的微服务框架，也是为了蹭微服务的热度，对粗粒度的服务照样可以使用spring cloud。

   中台思想

   大中台+小前台，敏捷灵活支持业务。基于阿里的影响力，中台思想也是很多人嘴中的大词热词，显得很高深。在熟悉SOA服务化的人看来，这个中台思想也不是啥新鲜玩意，在架构设计中很早就在使用，它本质上就是IBM的SOA参考架构模型，参考架构是一个架构模板，模型如下图。

    对中台的这种理解，不是一家之言，在工作交流中和提出这个思想的公司架构师做过确认。

 

  这个模型和DDD领域驱动设计中的服务分层分类（应用服务-》领域服务&领域对象，可以根据其在业务处理流程中的位置继续分层-》基础设施服务)是类似的，对DDD中应用服务和领域层服务的透彻理解见充血模型中的职责分配。

  在分层架构中，无论是技术中台、业务中台或组织中台，中层都是起到承上启下的作用。

  第一层Consumers层就是前台应用，贴近用户，它提供各种方便用户使用的通道channel。

  第二层是流程和服务编排，组合下层的服务。DDD中的应用服务(前台应用自身的应用服务)可位于第一层中，有时也可在第二层。

  第三层对应中台思想中的业务中台，这些服务是抽取各个业务线的共性需求，向下沉淀，通过服务化把这些能力开放出来。可见这些服务是比较稳定的，对应DDD的领域层服务(领域服务和领域对象)，它们是可重用的，可被多个前台应用共享的。在一个具体的架构中，就是各种服务中心，例如订单中心、用户中心。

  

  IBM SOA参考架构中还有更底层的服务，例如基础设施包括中间件，这个就是业务后台或技术后台、数据架构和业务职能BI（把这个服务化就是数据中台）、服务治理框架等。

   参考架构并没有限制不能使用DDD和微服务，抛开参考架构中的ESB后，中台思想和IBM SOA参考模型本质上没有区别，SOA参考架构是抽象的模板，概念模型，而中台这种说法更形象更通俗易懂而已，管理者和不怎么懂SOA的人大多也能听懂，也就是中台只不过是SOA服务化换了个马甲而已，是SOA服务化进行到深入发展阶段而落地和演绎出的一种形态，本质上没区别。

    大规模的深入的服务化改造，还涉及到组织结构的调整，这个就是康威定律所讲的内容，到一定的发展阶段，组织架构要和系统架构对齐，保持一致，打左灯向右拐是要出大事的。

    

   综上，从SOA服务化分层架构和DDD服务分层分类可以看出，叫或不叫中台，中台原本早就在那里，不增不减。对那些不熟悉SOA服务化和少见多怪的，也可以认为是把后台中贴近前台的一些业务逻辑(功能)划分出一层而产生中台或抽取前台应用中有共性的一些业务功能，沉淀而成。在熟悉架构分解本质和SOA服务化以及DDD(领域驱动设计)本质的人眼中，微服务和中台不是什么新概念，新瓶装老酒换了马甲而已。

 

   

   区块链

   单纯的区块链技术真能保证数据真实？其实它保证的是不能篡改数据，并不能保证数据真实性。单纯采用区块链技术，并不能避免虚假的数据写到链上，如果发生这样的事情，此时它保证的是链上的虚假数据不能被篡改，假的真不了改不了。

 

   没有慧眼，不了解技术和思想的本质、来龙去脉和演化过程，换个马甲就不认识了，容易被人忽悠迷惑和偷换概念，要有洞察本质、融汇贯通的能力。