企业信息化架构的选择，SaaS,ESB,中台

1.引言

企业的信息化应该是因地制宜,循序渐进的过程，好比骑自行车的人还想快些可能就学下电动车或者打辆的士,要一下让他开上小轿车就是不大现实了。在一些中小企业的”表哥”,“表妹”, 对于不同数据源的excel文件用宏和vba能够快速灵活的处理和统计。信息化要能贴地气的解决业务困难,促进业务的发展,选择最适合自己的方案即可。

2.中小企业的选择

每个行业现在都有不少云端的产品,云ERP,云OA,云CRM,云MES等,协同办公也有钉钉,企业微信等APP,付出少量的成本如果能解决业务中6到8成的问题还是不错的选择。

这类SaaS产品也有一些代价,数据放在别人的云端,如果对数据敏感可考虑找些开源或免费的产品自己搭建。

3.中大型企业信息化的问题

3.1 采购或自研

大多的企业可能会选择采购,行业软件供应商技术和业务都有积累,企业专注于业务数据和流程定义,供应商定制系统。

如何协作得好,采购能解决大多的短期的业务问题,但如果没一个整体的规划也会有一些问题。例如一碰到问题就是采购系统,可能多家不同的供应商,每个系统都是解决各自业务域的问题, 例如财务用财务软件,人事用OA,生产运营用ERP,MES等等, 每个员工每个系统都有一个账号,业务数据各自为政无法共用。

这个就是阿里提到”烟囱式”系统。随着互联网时代的到来,业务从线下到线上,企业内到企业外的交互,结果就是发现这些烟囱要交互起来有困难,如何解决这个问题我们参考3.2。

而自研通常是行业中的大户的选择, 这些大企业能够影响行业的标准和规则。多养一个技术团队成本看起来是高,但长期的看来,自研才能解决不断变化的业务需求,保证企业的竞争优势。

3.2 打通烟囱式的系统传统方案

供应商更多是以项目形式提供系统,完成各自的业务的逻辑和流程,通常很少提供对应的业务接口,扩展性有限。如果采购就只能协调原有烟囱供应商对接,可能采用的一些方式:

开放各自业务数据库给其它烟囱系统直接采访,这种方式比较直接暴力,只要了解所需业务的数据表定义即可, 但调用方要控制好采访压力和资源释放,别把业务数据库搞崩了。

这种方式一般在项目比较赶,供应商较难协调时才考虑使用。

3.2.2 开发各自业务接口

每个烟囱首先要开发业务接口供外部调用,例如SAP的PI可开发web service, JCO也可直连调用;Oracle EBS也可以把存储过程发布为web service。

不少企业会把ERP作为核心系统,例如SAP,Oracle EBS也支持二次开发不断的扩展业务, 核心业务放ERP,以ERP为中心打造周边辅助系统。这是一种风险低些的架构,不过中心化的ERP容易成为瓶颈,像SAP这种集成度越高的ERP没优化好的情况下,用的人多些就容易卡了,ERP最好能支持应用的均衡负载,数据库的读写分离/集群,甚至分表分库等方式扩展。

对于对等的烟囱系统业务依赖的时, 简单些可以直接调用对方开放的接口, 即点对点的调用,实际上现在流行些的微服务/RPC调用也是P2P, 内部的调用未必一定要上服务总线ESB。这种属于怎么简单怎么搞的解决方案,系统不多的时候开发和维护成本都可控些。

3.2.3 使用ESB整合业务接口

企业服务总线ESB在神坛也有几年了,以前一谈企业集成就基本和ESB扯上了。ESB的存在是SOA实施一个阶段的产物。企业采购了一些必需的系统,业务都跑上面积累了不少数据。随着互联网的兴起等原因要实现系统的互联互通, 每个系统可能不同供应商,不同的开发语言完成,按照3.2.2开放了各自业务接口后,通信协议可能也五花八门,http/json/web service,socket,甚至专有协议等。对点对的调用在系统和业务多的时候维护成本也不断增加。

而企业集成开始推崇使用ESB, 参考下Oracle ESB架构图。

相比点对点的调用,所有的调用都需要到ESB总线路由,数据转换清理,再分发到对应的服务提供者,对服务消费者来说请求数据格式和通信协议都得到统一和简化,隐藏了服务提供者实际的实现差异。ESB通常也配套了IDE,拖拖拉拉配置好Inbound, Outbound参数和规则, 少量一些编码即可对接,大量对接异构系统时效率较高。

无ESB不欢,当时SOA实施的首选基本都是ESB,厂商也投入大量的人力物力高级集成这个总线,让这个中间件高大上，所以ESB价格不菲。而一般的企业都尽量选择一些免费或开源的OpenESB, Mule等产品。

ESB是SOA前期探索的产物,从架构上看,它也是一个中心化的中间件,都经过ESB调用的链路长,协议转换会拖慢些,即使做了均衡负载/集群,在电商等高并发的情况下,SOA调用效率比点对点要低下,也没法规避ESB雪崩等问题。所以才有了后面的点对点的微服务架构和中台。

社会和技术都是不断发展,ESB虽然慢慢走下神坛,但也在不断的完善,也还是异构系统整合的一个选择方案。而且ESB在SOA,也为后面微服务的API网关,服务注册发现,均衡负载,链路监控,日志等各方面都提供了很多实践经验。

企业信息化无论哪种方案,最大的瓶颈应该是数据库。传统的关系型数据库,无论oracle还是mysql单表到一定的数据量后都存在性能问题,所以类似mycat这样的分片框架流行。

用NoSQL数据库集群后是傻瓜,不管怎么分片和存储,但在开发,设计,功能上的变化一般团队可能不适应,在级联查询,事务,性能等也有一些限制。

分布式数据库这几年开始稳下来,以阿里的Ocean Base和PingCAP的TiDB出名些,当然商用版的MySQL Cluster也算分布式数据库, 主要开发设计不用考虑数据分片,mycat都可以回家了。

对于中小企业的信息化,基于分布式数据库就省事了,可以傻瓜的认为用一个数据库存储所有数据,多个系统公用这个数据库。这种也是属于怎么简单怎么搞的方案,有点粗暴,这里是抛砖引玉。

不过个人比较看好Ocean Base,性能可以,这个基础设施讲不好真能干掉oracle。

4 企业信息化是否使用中台架构?

4.1 阿里中台介绍

以阿里为首的互联网和电商带火了微服务和中台, SOA又到了新的阶段。

阿里以前其实很造了很多烟囱,例如淘宝,天猫,1688,每个大部门自己玩自己的系统和数据。后面业务整合需要数据互通,就成立了共享业务事业部, 慢慢就开始了厚中台,薄应用的转型之路。费了大量人力物力之后,慢慢的共享服务的好处越来越明显。 新增个业务例如造个咸鱼,用户有了,商品等基础数据有了,很多业务不需要重复建设,充分的重用服务和资源。

这基本成为互联网公司的标杆了,业务中台,数据中台。

4.2 企业信息化是否需要中台?

文章开篇的一个准则,如果业务碰到问题,中台能更好的推动业务发展,则可以考虑。

中台是为了重用业务服务,减少重复建设, 它的实施基于分布式服务化框架。技术层面的也需要解决很多问题, 服务如何拆分,数据库如何分表分库, 开发人员分工的变化,服务接口如何通用, 分布式事务如何处理, 链路日志监控, 限流降级熔断,自动化持久集成和运维部署。对产品,开发,运维，工作量暴增,中台的成本是昂贵的。

阿里的中台也是一个过程,单体应用,到ESB打通烟囱,他们都经历过。 所以说企业的业务积累到一个度了,无论是上什么架构, 都是水到渠成的事情。企业的老总或者不怎么懂技术,但是业务的思考都是行家。再好的技术如果不能推动企业业务的发展带来好处,也是没意义的。