打破信息壁垒,建设一体化大平台

简介: 打破信息壁垒,建设一体化大平台

孤岛和烟囱

十几年前有个很火的概念

“信息孤岛”

指的是互相不关联、互相脱节

没有业务和数据流动的多个系统

本来嘛,系统是一个个建立

建设目标不同,使用人员不同

最后就成了孤岛

一旦需要联动、集成

就会遇到各种问题


后来,有了更高级的说法

“信息烟囱”

他比孤岛稍微好了一点

上下是贯通的

但是横向形成了信息壁垒

比如民政的数据

消防的数据

交警的数据

彼此自成体系


在新形势下

各种大数据、一体化平台慢慢兴盛起来

破圈,解决发展的不对称

确保安全可靠的前提下

实现数据共享,业务灵活传递

Facade门面模式

在编程领域,很早就有一种做法

通过统一的门面

将不同的功能集成在一起

比如我们有两个类

一个提供短信服务

另一个提供邮件服务

就可以采用门面集成

/**
 * 邮件服务类
 */
public class MailService{
    public void send(String mailfrom, String mailto, String content){}
}
/**
 * 短信服务类
 */
public class SmsService{
    public void send(String mobile, String msg){}
}

现在使用的时候

需要根据情况选择调用不同的service

但如果采用门面集成一下

就变成了一个类

public class FacadeService{
    private MailService mailService=new MailService();
    private SmsService smsService=new SmsService();
    public void sendMail(String mailfrom, String mailto, String content){
        mailService.send(mailfrom, mailto, content);
    }
    public void sendSms(String mobile, String msg){
        smsService.send(mobile, msg);
    }
}

这样无论发送什么

都只需要调用 FacadeService 即可

有什么意义吗?

这个代码的难度相当低

初学者也能看的明白

但意义何在?

就是为了包装一层吗?


门面模式的应用场景

通常是降低系统访问的复杂度

将多个复杂的程序整合

然后提供给使用者一个简洁的入口

把上面的例子改一下

假如 MailService 和SmsService 里

各自已经封装了数十个方法和内部属性

而 FacadeService 仍然保持不变

那请问,调用服务的人

让他选择调用2个基础类

和只调用门面类

是不是变得简单了呢?

系统演化

对于遗产系统

比如用了很多年的、或是其他厂商的遗产

改造的方法通常有四种:

改造、集成、继承、淘汰

一般是根据原系统的价值和技术决定


比如我们用Java开发

原来的系统是 vb 或 dephie 的

这个就很难继承下来

还有的系统虽然能访问

但简直就是代码shit山

看着就恶心


所以我们一般的原则如下:

技术水平高的系统:改造或集成
技术水平低的系统:继承
业务价值高的系统:改造
业务价值低的系统:集成
技术低,业务也低的话就要淘汰

采取门面集成

大家都用过微信

可以简单的认为

小程序走的就是集成的模式

根据入参的不同,提供大量的应用

而作为用户,只需要一个微信号就可以


这几年微信的野心很大

作为群众基础最庞大的生态

小程序的应用,实际上让微信成了最大的系统入口

无论是用户授权,OAuth,扫码登录,一键登录等等

让众多的应用放在一个统一的平台里

为什么很多人手里的app存活量少?

一是很多低质量的厂商自己作死

广告、消费陷阱等等

另一方面也是空间和代价的考量

现在让一个新用户安装软件

成本基本上在10-20元

诸位都见过滴滴、饿了么、拼多多拉新人有多疯狂


所以这种集成模式

其实还是对用户比较友好的

化繁为简

很多细节无需知道

好用就行了

Spring中的应用

我们最常见的Spring Boot

启动类里都有这么一段:

@SpringBootApplication
public class DemoSvrApplication {
 public static void main(String[] args) {
        ConfigurableApplicationContext context = SpringApplication.run(DemoSvrApplication.class, args);
    }
}

不知道有多人去研究过这个 SpringApplication.run();

这里面就封装了大量细节

包括创建bean容器、初始化bean工厂、上下文设置、监听启动

我们启动的时候控制台显示的一堆日志

就是在隐式的做了大量工作的体现

所以,如果您有以下的需要:

  1. 多个平台合并在一起,提供统一入口
  2. 多个相关功能,避免耦合
  3. 隐藏诸多细节,给使用者简单的入口

这些情况下,就可以考虑使用Facade门面模式

多说无益,动手开干

相关文章
阿里巴巴发布《城市数字孪生能力平台总体技术要求》企业标准, 促进数字孪生互联互通生态建设
2023年3月21日,阿里巴巴集团举办城市数字孪生企业标准发布及研讨会,发布了《城市数字孪生能力平台总体技术要求》企业标准。
阿里巴巴发布《城市数字孪生能力平台总体技术要求》企业标准, 促进数字孪生互联互通生态建设
|
数据采集 存储 供应链
大型集团企业数据治理实践,推进全域数据资产体系建设 | 数字化标杆
数据治理是推动大型集团企业转型升级、提升竞争优势、实现高质量发展的重要引擎。沉淀了丰富的集团型企业数据治理项目经验,助力客户构建全域数据共享中心,实现数字化升级。
420 0
大型集团企业数据治理实践,推进全域数据资产体系建设 | 数字化标杆
EMQ
|
存储 数据采集 边缘计算
车路协同云控平台建设实践
为车路协同产业链提供车路协同云控基础平台资源连接、数据接入层基础软件以及数据「采集-移动-传递-对接」整体解决方案,探索技术架构演进与大规模商业化应用落地。
EMQ
1169 0
车路协同云控平台建设实践
|
数据采集 安全 数据管理
协同推进主数据建设 夯实数字化建设基础
主数据是夯实数字化转型基础底座,是助力管理体系和管理能力现代化的重要举措。
|
安全 数据安全/隐私保护
安全体系也是互联网金融平台的核心竞争力
安全体系也是互联网金融平台的核心竞争力
168 0
|
存储 Cloud Native 数据挖掘
郑州商品交易所与阿里云达成合作 推进核心数据分析平台建设
5月20日,郑州商品交易所(以下简称“郑商所”)日前与阿里云达成技术合作,通过引入阿里云AnalyticDB云原生数据仓库,进一步提升郑商所数据平台数据分析效率和用户体验。
412 0
郑州商品交易所与阿里云达成合作 推进核心数据分析平台建设
|
人工智能 运维 架构师
大型企业中业务中台建设思考
近年来从互联网领域到传统行业竟争变得日益激烈,消费者的层次结构和个性化需求在快速发生变化,企业为了应对这种变化不得不进行业务的快速迭代,在此背景下IT行业里中台的概念逐渐火了起来,大家都在谈论或实施中台化战略,中台有什么魔力能有这样的号召力,各类企业特别是跨业态的集团化企业都希望通过中台战略解决自身问题,但是我们也看到一些企业在实施中台项目中出现了严重的问题和偏差,阿里巴巴张勇曾说过:“如果一个企业奔着中台做中台,就是死”,中台最早是由阿里提出的一种IT架构理念和方法,其实中台思想古来有之,只是在互联网时代给它赋予了新的涵意。
|
大数据 云计算 计算机视觉
大数据合成作战指挥平台建设,情指勤一体化管控系统开发
合成作战平台依托现代化科技手段,包括云计算、大数据、人脸识别、车辆识别、视频结构化等新技术,建立一个多警种共同使用的合成作战平台,为打击侦查、联合办案、合成作战增添有力的利器,从而提升了公安办案效率和增强办案效力。
263 0
|
存储 数据采集 人工智能
工业数据中台实践系列2 - 供给侧供应链优化
  1、引言   今年我们在制造行业上推出了工业数据中台,并依托工业数据中台主打几个行业场景解决方案,这其中供给侧供应链优化是其中最普遍的一个场景。之所以讨论场景的中台解决方案,是因为一直有一个想法,我们对客户讲数据中台,业务中台,在没有场景的情况下是很难让客户理解的,除非客户需要的就是一个大数据的平台或者技术中台等,究其原因最终这些我们经常讲的中台背后是具体落地的技术方
441 0
工业数据中台实践系列2 - 供给侧供应链优化
|
供应链
羽顺热能:进一步加强上下游供应商战略合作伙伴体系建设
羽顺热能:进一步加强上下游供应商战略合作伙伴体系建设