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

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

   微服务 

  先说微服务,它似乎是一颗新的救命稻草和银弹,不管它是否适用都往上扯。微服务真的是前所未有的新技术新概念?其实不是,微服务就是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(领域驱动设计)本质的人眼中,微服务和中台不是什么新概念,新瓶装老酒换了马甲而已。

   

   区块链

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

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

   
 

相关推荐