商城系统平台搭建的关键要素与AI技术的应用探索
746
2023-01-06
本文目录一览:
近期,Gartner、Forrester等行研机构陆续更新了低代码相关的报告,报告中对低代码的能力模型进行了调整。从整体方向上看,上述行研机构在评估低代码开发平台产品时,提升了数据模型/模型驱动的重要性,并且细化了开发管制(governance)相关的要求。
事实上,随着低代码应用场景的泛化和深化,国际上的主流行研机构已经明确了“低代码开发和传统开发方式在应用场景上一致”的大方向,并且按照开发复杂系统、大规模系统的标准,衡量低代码开发工具。
核心能力体系
在此背景之下,我根据对低代码行业的观察和理解,再考虑上中国特有的需求,整理出一份低代码开发平台核心能力,分为开发、扩展、体验和管制四个方面,供技术选型参考。
1. 开发
1.1 模型驱动开发
模型驱动是软件开发的成熟方法论,是企业级系统开发的通行做法。模型驱动开发大致可以分为三个阶段:
数据模型:根据数据库设计范式,制作出由数据表、关系、约束等构成的数据模型
业务模型:将业务逻辑构建在数据模型之上,形成完整的业务模型(也称领域模型)
交互界面:基于业务模型开发交互页面,编排业务模型以实现业务操作
1.2 可视化:UI设计
使用可视化的方式构建前端界面和前端交互行为。如果您的项目需要保持统一的VI,那么是否支持引入CSS文件也需要纳入考察项目。
1.3 可视化:逻辑处理开发
使用可视化的方式,在前端或者后端构建业务处理逻辑。对于有事务性要求的企业级应用项目,如ERP、WMS或财务,需要重点关注后端业务逻辑处理的开发方式。
1.4 可视化:系统运维
低代码开发平台应关注软件开发的全生命周期,部署、迭代、监控等环节的可视化,同样可以大幅降低软件的整体成本。
2. 扩展
2.1 数据库集成
数据库集成能力是打通“数据孤岛”的必备条件,也是成本最低的方案之一。是否能够连接外部的数据库,是否能够调用该数据库上存储过程等编程能力,对大企业的软件开发项目来说至关重要。
2.2 WebAPI集成
现代的软件系统和SaaS服务均以Web API的形式对外提供接口,用于集成。通过调用Web API可以让低代码开发平台具备更强大的开发能力和更广泛的应用场景。
2.3 编程接口
软件需求和IT环境的变化通常会超过开发平台的迭代,编程接口便是避免“卡在最后一公里”的最后一道防线。
2.4可扩展的组件生态
在编程接口的基础上,如果能够存在一个组件生态,让用户能快速找到自己所需的开发功能,避免“重复造轮子”,何乐为不为呢。
3. 体验
3.1 响应式页面支持
响应式页面可以分为流式布局和网格布局两种。支持响应式页面意味着用户无需针对特定的屏幕尺寸做专门的设计,可以大幅提升UI的开发效率。
3.2 定制化的原生APP支持
为了充分利用硬件的特性,针对iOS或Android开发原生APP依然没有被抛弃。是否能构建从Logo到功能,全定制化的原生APP对于某些项目来说,依然是必须项目。
3.3 本土化移动端支持
移动办公在国内基本上等同于钉钉和微信,所以,低代码开发平台需要具备与这两个IM软件无缝对接的能力,从页面嵌入到用户集成,不容忽视。
4. 管制
4.1 Web版IDE
相比于桌面版的IDE,Web版具备更快速的部署、更统一的版本等优势,对于大型项目开发团队而言,为此牺牲一定的开发效率都可以接受。
4.2 版本管理
企业级应用的高复杂度和频繁的需求变更决定了版本管理的重要性。事实上,在专业开发领域,版本管理已经成了标配,并基于此衍生出了完整的项目管理方法论。
4.3 代码仓库管理
与代码类似,用户使用低代码工具开发的资产也是公司或团队的财富,如何安全可靠的保存这些资产,将其存放在位于局域网或互联网的Git等代码库,配置访问权限是个好思路。
4.4 局域网部署
在中国,依然有很多企业对数据和应用程序的可控性提出非常严苛的要求,如果用户需要为他们开发核心业务系统,支持局域网部署,在完全没有互联网的情况下也可以开发、部署和使用就成为不得不面对的现实。
国内外典型产品横评
为了直观的展示核心能力体系,我选取了国内外几个典型的低代码开发平台产品(outsystems、powerapps、活字格、钉钉宜搭)进行横评。这里的评价仅为定性,不涉及定量。一家之言,仅供参考。
先说结论:无代码和低代码根本不是一个东西。
何为低代码?何为无代码?按着字面意思来理解也无碍。
1、低代码:在使用少量代码apaas私有化部署的情况下,就能按着自身需求搭构出一个软件或者系统,且后续还可以根据自身需求自由加载控件,扩展性相对较强;
2、无代码:在完全不使用代码的情况下,就能搭构出预设的软件或者系统,这过程主要是通过封装模块搭建的形式来实现。
把搭建系统看做房子装修,则通过低代码搭建出来的是毛坯房,后续房主还得适当装修下(添少量的代码)才能入住;而通过无代码平台搭建出来的是精装房,直接省去apaas私有化部署了装修的步骤,拎包就可入住。
虽说“精装房”无代码会更省心省事,但是其存有的局限性不可忽视:
1、无代码仅适用于特定场景的小型应用程序开发,无法胜任一些复杂的场景,应用场景存在一定的局限性;
2、无代码没有更多的自由发挥空间,不支持自定义扩展配置,不支持与第三方系统或本地系统集成,扩展性和集成能力非常有限;
3、无代码平台大多采取的是云端部署的方式,不支持私有化部署,数据安全性堪忧。
而“毛坯房”低代码,恰好就弥补apaas私有化部署了低代码的这两点不足。
1、相比无代码,低代码更擅长在复杂场景下帮助用户完成软件或者系统的开发;
2、低代码具备强大的扩展性和集成能力。用户可以根据自身的需求灵活自如的个性化配置,加载自身所需的功能控件,自由与其apaas私有化部署他系统集成,互通调用数据;
3、低代码大多采取的是私有化部署的方式,直接将系统部署在本地服务器,数据的安全可控性更高。
云计算起源于大型互联网企业。对于互联网企业,成本压力和指数级的业务增长压力使他们关注于物理资源的利用率和应用的可扩展性。在应用服务器这层,通过Cluster Session来实现水平扩展;在数据存储这层,采用基于BASE模型的NOSQL数据存储来实现扩展。。
(1)基于商业软件的部署方式:Application- Framework/Libs - Websphere/Weblogic + RDBMS(2)基于开源软件的部署方式:Application - Frameworks/Libs - Tomcat/JBoss + RDBMS(3)云环境下的部署方式:Application - Frameworks/Libs - PaaS(Goole App Engine, Amazon)这种情况下,PaaS实质上就是一个预先装好的Web Container和一组公共服务,如数据存储服务(不一定是关系型数据库)、消息队列、集中式session及cache等等。对于个人用户或者简单应用来说,公有云PaaS平台使得开发人员仅关注应用逻辑开发本身,不用把精力花费在基础实施和应用的扩展和维护上。所谓企业级PaaS平台,主要包含两类,一是大型企业内部的私有云PaaS平台,另一类是面向ISV厂商的PaaS平台。然而对于企业级PaaS平台,PaaS不仅仅是云环境下的应用部署平台。 抛开安全问题不讲,私有云PaaS平台和公有云PaaS有如下核心区别:(1)复杂的多租户模型:对于公有云PaaS平台,其租户模型是 (用户- 应用 - 应用实例),一个用户可以部署多个应用,每个应用可以有多个运行时实例,应用实例共享资源池。对于一个大型企业,一个大部门可能是一个租户,大部门下面的子部门也是一个租户;或者一个SaaS应用系统的一个实例就是一个租户。对于租户的资源使用,大部门租户是共享资源池里面的资源,也可能某些关键租户需要独占一些资源以保证安全。(2)已有应用的兼容:企业的历史应用都是基于关系型数据库的,某些PaaS平台不支持关系型数据存储,即使是简单的已有应用都无法迁移到PaaS平台上。(3)复合应用的构建: 企业On-Premise应用在很长一段时间内都是要存在的,私有云PaaS平台要成为On-Premise和公有云之间的桥梁。私有云PaaS平台除了是应用部署平台外,还需要提供集成和方便构建复合应用的能力,就是Gartner所提的iPaaS能力。 企业级PaaS平台不仅仅是应用部署平台,而且是复杂多租户环境和复杂应用环境下的共享基础设施平台,是On-Premise部署通往公有云部署的必经之路现在拥有PAAS平台技术的厂商
apaas和ipaas
简单的说,PaaS平台就是指云环境中的应用基础设施服务,也可以说是中间件即服务。PaaS平台在云架构中位于中间层,其上层是SaaS,其下层是IaaS。在传统On-Premise部署方式下,应用基础设施即中间件的种类非常多, 有应用服务器,数据库,ESBs, BPM, Portal, 消息中间件,远程对象调用中间件等等。对于PaaS平台,Gartner把它们分为两类,一类是应用部署和运行平台APaaS(application platform as a service),另一类是集成平台IPaaS(integration as a service)。 人们经常说的PaaS平台基本上是指APaaS。
paas对互联网产业的影响
平台即服务(Platformas a Service, PaaS)是软件即服务(Software as a Service, SaaS)的延伸。SaaS提供的是定制好的远程软件服务,比如当你订购一个网络销售系统软件,就可以直接使用,不需要代码开发,但是缺点是客制化困难。PaaS也是远程订购服务,但是你购买的是平台模块服务,如计算能力、数据库、储存和消息传送等。底层的平台已¾¬帮你铺建好,你需要开发自己的上层应用。
首先,技术门槛降低让应用更容易生成,而间接鼓励更多的商业模式创新。尤其是资金花在软件和硬件的比例会减低,给初创公司带来更大的生存空间;再来,可以有更多的平台服务架构在现有的PaaS上(Platform over PaaS),使得服务的种类多样化。这也会促成生态链的形成;最后,公司的合并门槛减低,如果两家公司用的是同一个平台服务,那么就没有技术整合的问题了。当然,PaaS要大力发展还是有一些困难得克服,例如vendor lock-in,也就是说API和数据都还不是标准化,使得应用迁移变得复杂。再者,网络的连接性也是一大问题——当你的应用因为任何一端的网络而没办法连上平台服务时,你可能没有任何其他的备份方案。最后,老实说国内的互联网产业要能真正提供PaaS还有一段路得走,毕竟技术门槛不是太低,尤其是分布式计算的构建不是一蹴而就的。
PAAS平台应用代表
国外:Google、Salesforce、Amazon
国内:八百客 用友 百度BAE 新浪SAE 阿里Ali 魔泊云(MoPaaS)
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。