企业中台布局和IT架构微服务转型杂谈

关于传统企业IT架构转型，中台和微服务架构布局在我头条前面的文章外面都有比拟系统的整顿和论述，只管云原生概念在2013年就提出，然而2020年可以算作是云原生的元年，同时企业IT架构转型，微服务化和逐渐迁徙上私有云也将是未来多年的一个技术开展趋向。最近联合和协作同伴，客户的沟通交换，对一些罕用的疑问启动整顿和说明。

中台和微服务布局

关于中台布局实践上可以了解为传统企业架构和消息化布局，传统SOA架构布局的一个子集。其外围还是业务驱动IT，基于业务流程和业务对象梳理剖析，识别外围可复用的业务组件和才干。特性业务才干下沉，提供粗粒度接口给下层经常使用。

中台自身是一个业务概念，而非技术概念。

能做中台布局的不是技术很牛的新兴咨询公司或软件服务商，而是传统的扎根在某个垂直业务畛域的传统咨询公司或软件服务商。即对垂直行业业务了解的深度，传统的咨询布局才干，远远超越技术才干。

一个新兴的企业四处去给客户做中台布局，这个是不适宜的，没有业务畛域的积淀你如何给他人布局中台，如何识别可重用的业务才干。你没有业务积攒和积淀，再好的方法论也不可指点你通常。只管我文章外面整顿中台布局方法论，雷同我不相熟的业务畛域我实践也不可给他人做布局。

相熟一个技术架构思维或许须要1周期间，然而相熟一个垂直行业至少须要1年甚至更久。所以做技术布局相对容易，然而做业务和中台布局难，其难点不在于方法论，而在于业务积攒和积淀。

微服务-不要将规范僵化

实践上咱们在启动微服务架构转型，包含和客户探讨微服务化的环节中往往发生两个极其。一种状况是大运行运行层拆分了，然而数据库还是一个;还有一种状况是严厉地去做到拆分的微服务和数据库1对1。

关于第一种状况因为DB没有拆分，实践上依然是一个紧耦合的系统。而第二种状况微服务拆分后造成少量独立细粒度的数据库实例，进而带来少量的散布式事务疑问。而实践上更好的做法应该是依据企业业务域的状况启动折中，按业务子域来启动数据库拆分，而业务子域外部的运行层，还可以拆分为多个微服务。

包含在微服务虚施中，经常有人会说你的架构前后端没有分别，不是微服务。而实践上台后端分别雷同不是微服务的必要条件。

比如有些客户在实施微服务的时刻，只管前后端分别，然而后端提供的API接口服务所有都是细粒度的，同时和前端方法1对1，这样的前后端分别拆分并没有表现畛域才干，服务可复用等主要特性，反而是参与了前后端协同和联调的复杂度，这样的分别没无心义。

DevOps首先是环节，其次才是工具集成

关于DevOps，只管在我前面文章也详细说明了的咱们布局和研发的DevOps撑持平台。然而一切人还是要看法到DevOps首先是环节改良和提升，其次才是工具集成和智能化。

比如咱们看到一些企业实施了CI/CD集成，环节智能化等，然而你会发现从用户需求搜集到版本布局，到最终的开发成功和上线，整个环节控制还是很凌乱，有了工具依然发生需求，研发，测试人员少量的人工沟通和协同。那么DevOps实施的意义何在?

因此，关于DevOps首先是一种矫捷和继续集成和交付环节的改良，其次才是经常使用什么样的工具和技术。技术往往很难反推环节提升和改良，环节改良须要的是组织，团队和文明的改良。

大数据平台到数据中台

可以看到，很多做数据中台的服务商实践就是原来做大数据平台的服务商。那么大数据平台和数据中台终究有什么样的区别?

关于大数据平台你可以了解为一个纯正的数据技术才干平台，外面自身是空的。就像咱们了解ESB总线一样，自身是一个技术平台，一开局没有接口服务注册在下面，须要你自己不时地接入新的服务，才干够构成服务目录体系。

而关于数据中台则是基于一个大数据平台的技术底座填充了详细的数据资产，这个数据资产须要启动分层，须要启动形象建模，须要对外提供可复用数据服务才干。

因此数据中台树立难点素来不在大数据技术平台，而在于外面的数据树立，如何对数据启动建模，如何采集数据，如何荡涤数据，如何形象聚合等。而这个雷同又回到了中台布局的主要，即须要业务域业务才干和阅历积淀，你才干够做这个事件。

繁难来说假设企业要做数据中台，新兴的很多大数据平台或数据中台厂商不肯定靠谱，反而是哪些传统的垂直畛域常年做BI布局实施的厂商更值得拜托。

从云原生到企业上云迁徙

我在前面谈到过，关于阿里，华为和腾讯等私有云厂商，2020年在云原生处置方案，协助传统企业上云上宣传得很猛，只管整个云原生是技术大趋向，然而企业肯定要看法到从传统的企业外部IT架构迁徙上云依然是一个相对漫长的环节。

特意是企业已有外部私有云或数据中心，曾经有少量遗留IT系统的状况下，在业务延续性保证，如何确保平滑迁徙难度极大。

各个私有云厂商都推出自己的迁徙方案和方案，包含自己的DevOps研发一体化平台加长到企业外部，只管易用性和繁难性在增强，然而对企业的强绑定也在增强。繁难来说你驳回了某个私有云服务商的方案和服务，实践前面你要脱离是相对艰巨的事件。

其次，前段期间做了下繁难的比拟，即不间接购置虚构机而是间接购置数据库服务，发现全体每年的老本相对高。有时刻思考间接购置云服务厂商的技术服务才干，然而实践上很多时刻你依然须要有运维工程人员，这个老本并没有省略掉。

同时因为企业IT系统是逐渐迁徙的，企业外部私有云和私有云将并存相对长一段期间，包含有些传统的外部IT系统在性能需求，安保性等方面往往并不适宜上云，这些都肯定思考分明。

服务控制和管控才干

有些企业自觉地崇敬新技术，总宿愿自己在新系统的开发中驳回最新的技术，最高性能的技术。然而实践上在前期管控运维上都发生了疑问。

关于微服务而言也一样，刚开发的微服务拆分，接口定义并没有马上发现疑问，然而最终到了开发前期乃至上线的时刻才发现微服务拆分的太细，微服务间的接口交互太多。也就是说微服务拆分后，各个微服务间依然是紧耦合形态。

系对抗上线，发现整个微服务环境齐全不在自己的掌控范围，运转缺点疑争辩处置，日志难以排查，接口变卦少量依赖造成上线缺点等。这些都是典型的整个IT组织的架构才干，服务管控控制才干跟不上造成的，刚开局用新技术很爽结果到前面留一个不可管控的烂摊子上去。

中台和微服务

关于中台构建肯定要驳回微服务架构吗?

在前面文章也谈到过，现实化的中台构建驳回微服务架构是最佳的方式。然而中台的外围是特性业务才干下沉并对外提供，能够撑持下层运行极速构建。

那么企业存在少量遗留IT系统的时刻，所有颠覆原来的微服务化就不是最佳的方法。更好的方法是围绕你构建的中台能否提供可复用的特性业务才干为最终权衡规范。假设做到了，企业就构建了很好的中台。底层能否经常使用微服务反而不是主要点。

因此中台和微服务只管严密联合，然而实践上没有肯定相关。

中台的构建可以不驳回微服务，可以驳回传统架构，也可以经过对遗留IT系统接口适配的方式来构建。而关于微服务雷同不肯定表现中台特色，微服务外围依然是在于传统大单体的拆分，拆分后的接口服务可重用性是充沛条件而非必要条件。

不要神化低代码开发平台

从新回归下在2020年技术开展，发现低代码开发平台反而是一个热点中的热点，发生了少量的低代码开发平台的厂家和云服务商。有些是传统的做BPM类的厂家，也有些是自身就是做极速开发平台的厂家，当然还有些齐全提供零代码组装的平台。

没有银弹说了这么多年，这个短期不会有大改观。

那么低代码平台自身的难堪点在哪里?

关于中小型企业来说，须要的并不是低代码开发，而是间接的SaaS服务，关于SaaS服务产品能够提供一些灵敏的流程，权限，数据项的性能才干足够。而关于大型的企业来讲，很多业务流程和业务场景，特意是复杂的业务规定，低代码平台并不能处置。即使处置依然存在少量的复杂脚本代码。

低代码平台假定了每个对象，每特性能相对来说都尽量独立，然而实践上关于复杂的业务来说对象之间无关联，性能之间有协同和集成，业务逻辑难性能等。这些不是低代码平台能够处置的疑问。

假设真要做低代码开发平台，你会看到惟一好的方向是垂直业务行业+业务系统。越做到垂直，越容易将可复用的物品形象进去提供。也就是说实践是提供了一个垂直行业+垂直业务下的一个业务平台才干，这个才是最有价值的。