微服务 RPA和低代码炽热面前的一些冷思索 中台

这个周末我去加入了2021年华南CIO大会，发现基本上每年大会都有一个热点，比如往年的热点就是低代码开发平台。

咱们可以回忆下最近几年的热点变动。

就我自己的文章输入来看，基本上也和这个大趋向合乎。比如我17年左右会更多地写微服务架构设计和实施方面的文章，18，19年输入了不少关于中台树立的文章。而最近几年关器重心则是云原生全体处置打算和低代码开发平台。

在IT行业，各种新兴技术层出不穷，互联网大厂的各种造词才干也相当弱小，也让每年基本都有新热点和新技术发生。

相似19年或许刚兴起低代码开发，而到了往年可以看到做低代码平台的各种厂商，不论是做SaaS服务的，还是传统toB实施的，还是围绕腾讯，钉钉生态的。预计至少有上100家企业在做低代码方面的产品。造成低代码整个行业也处于群雄逐鹿和凌乱的局面。

在上半年，ThoughtsWork的徐昊写了一篇文章，谈到低代码平台是行业毒瘤，首先这个看法我团体不认同，任何新事物都有其存在的价值和情理，也无法能去处置你一切的疑问。而是应该在适合的时刻驳回最适合的方法。

低代码平台自身是好物品，然而很多厂商将低代码平台吹牛来无所不能，再复杂的系统和规定都能够零代码，拖拖拽拽就成功，这就是齐全不讲武德了。所以低代码平台不是行业毒瘤，反而是厂商竞争中的脱口而出和瞎吹牛才是行业毒瘤。

回忆下中台的概念也是雷同的情理。

中台自身是一个很好的概念和思维，强调将企业特性业务才干下沉，而后构成可复用的业务才干中心提供应下层运行，让下层运行能够灵敏矫捷的去开发。

这个思绪自身没有任何疑问。

然而很多做中台的厂商，特意是很多互联网进去守业的厂商，一味地去夸张中台的作用，给企业画大饼，搞个中台就无所不能，企业原来已有的IT系统也要所有改一遍，去建大而全的中台才干而不是思索如何保管企业遗留IT资产。这些也造成了少量的中台名目最终树立失败，或许基本没有起到预想的成果。

这并不是中台的思绪不好，而是厂商夸张宣传最终又没有成功最终的成果和指标，造成了用户继续少量反噬，这不能怪用户只能怪厂商。

再回来谈微服务也是雷同的情理。

发展个3到5年，预计很多企业也被微服务搞死过。

要素也很繁难，自身一个单体运行运转得好好的，最终被拆分为20多个微服务，造成多个微服务间集成复杂，散布式事务失控，后续的疑问排查艰巨，运维监控艰巨等一系列的疑问。

这自身不是微服务思维不对，而是运行不对。

其一就是企业在没有到达必定的IT控制管控才干的时刻自觉上微服务，其二就是前期的架构建模阶段对微服务拆分不正当造成拆分太细，或许拆分后的微服务间紧耦合。

微服务思维自身不应该去背这个锅。

在去年我加入华南CIO大会的时刻，RPA机器人火的一塌懵懂，据说往年有些RPA厂商或团队曾经遣散。

那么RPA机器智能化这个终究好不好?

雷同的情理，任何一个新颖事物的存在都有其情理。RPA机器人和智能化技术整合处置了传统业务系统底层集成艰巨的疑问，将重复的上班智能化掉。

这个思绪没有任何疑问。必定有其运行场景和运行价值。然而要看法到的是RPA更多是一个折中打算，而不是指标打算。

为何这样说?

假设一个甲方企业自身有才干去做底层业务系统间的数据集成和接口集成，然而你自己偷懒不做，而是经过下层RPA的思绪去处置疑问。那么就是一种显著的治标不治标的方法。

一根大树，自身底层的多个树根应该集成和盘错在一同构成合力，撑持下层的枝繁叶茂。然而如今底层这个树根间集成不做了，前面在树枝和树叶上拉绳子，捆线条。只管这样可以暂时处置疑问，然而最终这个树前面越难再开展和生长，哪天突然倒下也不是无法能。

所以当我从新思索这些炽热概念后，给出一些关键的思索总结如下。

微服务

重申准则，就是你在没有明白需求的状况下不要轻易去拆分微服务。即使你用微服务开发框架，也可以不做大的拆分。大局部企业来说，实践业务并发量都还没有到必定要微服务化才干够处置疑问。

其次，运行裁减优先思索传统单体形式下的裁减方法，相似集群裁减，数据库读写分别等。也可以驳回按子组织水平裁减。

中台

假设你的企业自身曾经有必定的信息化树立基础，那么构建中台的最佳做法是对已有遗留IT系统中可复用的业务才干启动梳理，基于SOA的思绪来构建一个业务服务共享中心。而不是全新去构建一个中台。

关于数据中台来讲，假设没有做细粒度的微服务拆分，数据反哺业务的疑问也不要求数据中台来处置，间接在业务中台或传统遗留业务系统里处置即可。因此传统企业构建数据中台，不是谋求数据服务放开并反哺业务，而是数据整合后的剖析和应用，思绪依然或许是传统的BI系统构建思绪。

RPA机器人和智能化

关于RPA是一个折中打算而非指标打算。当企业面临诸多遗留系统底层接口集成艰巨的场景的时刻，可以驳回RPA形式来处置反停上班的智能化协同疑问。然而在有条件的状况下，依然还是以底层数据和接口集成为主而非下层的界面协同集成。

RPA不要越做越大，这个前期保养将是一个大疑问。一个是外围逻辑自身不清楚，一个是底层业务系统自身也处于变卦的不稳固形态。

低代码开发平台

在低代码平台自身的行业规范规范，成熟度没有到达前。企业不要将外围的业务系统放到低代码开发平台上。

低代码平台企业可以做一些尝试，可以将相似OA，名目控制，运维控制等偏工单和流程类的业务系统构建在低代码开发平台上，积攒相关的通常和运行阅历。

最后就是低代码开发平台在选用的时刻要思索不要被平台厂商绑架的状况，任何低代码开发平台开发成功的运行一个基本要求就是能够脱离低代码平台运转，并具有足够的高可用和裁减性要求。