云原生时代下的App开发.pdf

卷首语作为国内移动互联网、云计算领域的行业巨擘，阿里巴巴在大前端、云原生领域有着丰富的实战经验。我们从 2016 年开始逐步将阿里集团内部成熟的应用中间件云化输出，并在 2018 年推出了移动研发平台 EMAS（https:/ 已经逐渐成长为横跨多端（移动 App、H5 应用、小程序、Web 应用等）场景的云原生应用研发平台，基于广泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），为企业、开发者提供一站式的应用研发管理服务，涵盖开发、测试、运维、运营等应用全生命周期。为了让大家更全面地了解 EMAS 产品背景、产品内容以及相应的应用案例，特此推出该电子书，希望对广大开发者们有所帮助。目录1.EMAS 产品背景5端应用研发进入云原生时代52.EMAS 产品全景介绍18开发更便捷，阿里云推出一站式应用研发平台 EMAS 2.0183.EMAS 客户案例21杭州银行：坚定投入移动化战略，借助 EMAS 研发平台迈入移动开发 3.0 时代214.隐私保护政策下 EMAS 的产品升级27EMAS 发布最新隐私协议，为客户信息安全保驾护航275.EMAS 旗下移动性能测试29云上的移动性能测试平台296.EMAS 旗下低代码 mobi 产品背景35什么是低代码（Low-Code）？357.EMAS 旗下 serverless 小程序开发60基于小程序云 Serverless 开发微信小程序6051.EMAS 产品背景1.EMAS 产品背景端应用研发进入云原生时代作者|阿里云 云原生应用研发平台 EMAS 杨镔（泠茗）多样化用户体验（Multiexperience）与大前端随着云计算、移动化、IoT、AI 等技术概念地落地和持续发展，社会的数字化进程在不断加速。Gartner 近期发布了新的企业应用架构方法论 MASA（Mesh Application and Service Architechture，网格应用和服务架构）1，融合近 5 年流行的技术趋势，为广大企业信息化的供应商、开发者和企业用户定义了更广泛的企业数字化应用架构模型。简介：随着技术的发展和各种用户端场景的涌现，业务前台形式变得更加多样，“面向多样化的端场景提供无缝的、一致的数字用户旅程”已经成为了新时代企业应用架构的关键目标，同时它也是当下大前端技术发展背后的核心业务牵引。基于阿里云在过去几年服务海量用户的经验沉淀，本文总结了新的基于云原生技术的端应用研发范式，期望为广大开发者、企业提供云计算时代面向企业业务前台的应用研发方法论。1.EMAS 产品背景1.EMAS 产品背景云原生的研发模型旨在降低业务的技术风险，让开发者可以更单纯地专注于自己的业务。面向端应用场景，云原生技术理念同样适用。Gartner 在 2019 年定义了一条全新的技术赛道：Multiexperience Development Platform（MXDP）3，用以描述那些通过敏捷、现代化的技术能力帮助企业高效地实现 Multiexperience 的研发平台，其能力矩阵示意如下图：从 MXDP 的关键元素构成我们可以看到，除了传统的研发工具类组件外，云原生技术成为了MXDP 最核心的技术元素，其中的典型技术包括：1.EMAS 产品背景1.EMAS 产品背景性能测试服务，支持各类应用崩溃、ANR、卡顿、IO、CPU、内存等关键性能指标监测和评估；自动化测试引擎，支持测试用例编写、回放和管理；远程真机能力，支持设备的云端访问；智能 Monkey 与 AITest 等智能化技术驱动的测试能力；发布域：端应用的目标发布对象是海量的终端设备，生产发布受应用市场审核限制，因此，可靠、精准、定向的应用分发能力是应用生产分发的关键技术要求，包括：企业内分发能力；支持软件定义的灰度能力，支持面向不同的地域、网络、机型、渠道及其他自定义标签进行灰度分发；面向不同渠道的生产发布能力；版本管理与归档；运维域：面向端应用的运维体系应始终围绕问题的感知，问题的定位，问题的修复展开，在传统的 Metrics，Tracing，Logging 基础之上，我们特别强调面向端的 Hotfix 的能力，这是区别于后端应用形态的特殊之处。成熟的端运维体系应包含：面向端应用的 APM 能力，支持包括启动速度、页面加载、崩溃、网络性能、API 性能等在内的监控报警体系，并能与后端 APM 联动进行基于事务的访问追踪；面向端应用的远程日志能力，支持实时的终端日志记录和管理，加速问题的远程诊断；面向端应用的热修复能力，支持针对不同设备平台的代码、资源热更新；运营域：端应用作为企业业务入口，是企业面向终端用户的关键界面，必须时刻洞察用户的行为、倾听用户的声音，驱动业务的敏捷迭代。面向 App 的数据分析以及舆情反馈能力是DevOps 的关键闭环之一。数据分析应具备：面向全端的用户行为数据采集能力，包括小程序，APP，H5，PC，WEB，IoT 等；易用的终端埋点工具：支持代码埋点，自动埋点，可视化埋点等；1.EMAS 产品背景1.EMAS 产品背景数年前就已出现：后端即服务（Backend as a Service，BaaS）4是典型的遵循 Serverless设计理念的服务形态，早在 2012 年 BaaS 便在开发者社区中传播并因其便捷的使用模型而深受开发者喜爱。比较典型的 BaaS 服务包括消息推送、用户认证、云存储、云数据库等。由于 BaaS 服务大幅削减了企业在后端研发力量上的开销，其在端应用场景得到了大范围地应用。但 BaaS 核心解决的主要是垂直场景化的后端能力抽象，并没法支撑业务本身的后端逻辑部分。Function as a Service（Faas）5的出现弥补了这一空缺，并使得 Serverless 的架构范式能够面向端应用场景提供更加完整的闭环。FaaS 是一种软件构建和部署的新方式，基于事件驱动模型，以函数粒度为开发者提供业务代码的托管环境。这种架构模型在数据处理、Backend for Frontend、移动应用、IoT 应用和 Web应用等场景有较常见的应用空间。综上我们可以看到，面向应用的 Serverless 架构包含了 BaaS 和 FaaS 两种服务形态，为了完整地支撑端应用的场景需求，成熟的 Serverless 引擎应包括：消息推送支持在服务器与客户端间建立可靠、省电的长连接，面向 Android、iOS、Web、IoT 等端应用提供下行消息推送能力。1.EMAS 产品背景1.EMAS 产品背景运维成本开发者不必再关心底层计算资源的容量与日常运维问题，所有基础设施维护将会由 Serverless 服务商负责解决并对开发者透明。削减的运维成本，弹性的资源使用和可扩展能力都将帮助开发者更好地专注于业务本身的增长。研发效率完整的 Serverless 引擎提供了面向端应用的绝大部分场景能力的支撑，使得应用的研发非常便捷并易于维护。而在传统的研发模型下，代码开发、环境搭建、容量压测、集群扩容、应用部署等环节都会带来巨大的时间成本。低代码，应用研发形态的新变革云原生技术的出现使得传统业务架构大规模地向云架构转型，软件开发效率在这个阶段也得到了明显地提升。然而数字化时代，各种应用场景地涌现，业务对 IT 面向市场的响应即时性也提出了更高的要求。在跨时代的技术演进浪潮中，Low-code Development Platform（低代码平台）6快速浮出水面，并伴随多样化的端应用场景开始加速普及。低代码技术为软件研发效率带来的不仅仅是提升，更是变革。1.EMAS 产品背景1.EMAS 产品背景求变应变，永不止步成就技术革新作为国内移动互联网、云计算领域的行业巨擘，阿里巴巴在大前端、云原生领域有着丰富的实战经验。我们从 2016 年开始逐步将集团内部成熟的应用中间件云化输出，并在 2018 年推出了移动研发平台 EMAS（https:/ 已经逐渐成长为横跨多端（移动 App、H5 应用、小程序、Web 应用等）场景的云原生应用研发平台，基于广泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），为企业、开发者提供一站式的应用研发管理服务，涵盖开发、测试、运维、运营等应用全生命周期。截止到今天，伴随云计算的迅速普及和发展，我们已服务了 15 万以上的企业与开发者。（EMAS 开发者版套餐免费订阅）。在海量的生产实践中，我们也看到了云原生技术在端应用场景下所面临的的关键挑战：研发心智的改变对于所有开发团队而言，前后端团队的定义根深蒂固，协同界面已成自然。然而随着 Serverless 等云原生技术地广泛应用，在越来越多的端应用场景中，开发团队仅需前端开发人员即可以闭环完成应用的研发和上线工作；在应用架构维度，Serverless FaaS 带来的是基于事件驱动，无状态，函数式逻辑片段的全新范式，与传统的应用模型有着较大的区别。改变即成本，更关键的是改变背后不是纯粹的技术，还有组织的变革，生产关系的变革。技术成熟度无论是 Serverless FaaS 还是低代码开发，都属于商业导入期的技术，产品化完善度还有欠缺，所能覆盖的场景也有一定的局限性，对于主流的复杂应用场景，Serverless FaaS 还需结合传统微服务等架构形成混合式的 Serverless 应用。在系统可观测性，研发调试便捷性，函数启动性能，函数执行时长等技术关键控制点上依然有较长的路要走。1.EMAS 产品背景1.EMAS 产品背景REFERENCES1 Use MASA to Deliver an Agile Multiexperience Enterprise Application Architecture,Gartner,20192 Top 10 Strategic Technology Trends for 2020:Multiexperience,Gartner,20203 Technology Insight for Multiexperience Development Platforms,Gartner,20204 https:/en.wikipedia.org/wiki/Mobile_backend_as_a_service,WIKIPEDIA5 https:/en.wikipedia.org/wiki/Function_as_a_service,WIKIPEDIA6 https:/en.wikipedia.org/wiki/Low-code_development_platform,WIKIPEDIA7 https:/en.wikipedia.org/wiki/Hype_cycle，WIKIPEDIA2.EMAS 产品全景介绍2.EMAS 产品全景介绍EMAS 新能力从服务开发者提高开发效能、应用质量，到更好的帮助客户实现业务增长、变现等核心诉求；近期还将推出视频点播/直播的音视频能力、云码广告的流量变现能力、AI 工具箱（OCR）、号码认证平台服务等，尽请期待。开发者扶持计划阿里云此次还升级了开发者扶持计划，EMAS 2.0 公共云版本将全面升级为订阅服务模式，面向广大开发者，提供免费的的开发者版，包括 DevOps、平台服务、用户增长在内的相关板块的一系列免费服务支持。面向一定规模的企业，将提供企业版订阅服务，提供增值产品能力以及专属钉钉技术支持。EMAS 2.0 的订阅模式将会更大规模地让利开发者，帮助大家开启云端技术，智造未来应用。EMAS 产品技术负责人杨镔表示，EMAS 2.0 将全面利用云计算的服务模型优势，结合阿里巴巴经济体的多元能力沉淀，为开发者提供更完善的应用研发服务。并基于全新的六大核心技术理念（一云多端、云端一体、云原生、低代码、AI 驱动、链接业务）进行此次升级。一云多端，Multiexperience提供多样化用户体验，面向包括移动端、Web、小程序、PC、IoT、AR/VR 等场景实现无缝、一致的数字用户旅程。云端一体，One-Stop一站式提供端开发工具与后端应用构建和托管基础设施，企业仅需具备前端技术栈的专业人才即可低成本完成端到端应用开发。云原生，Cloud Native通过 DevOps，Serverless 等云原生标准技术赋能端应用开发，实现高效率研发、自动化交付、低成本运维。低代码，Low Code通过可视化应用搭建引擎实现低成本的应用开发和维护，为开发者提供 Pro Code 和 LowCode 两种应用研发引擎。2.EMAS 产品全景介绍3.EMAS 客户案例3.EMAS 客户案例杭州银行：坚定投入移动化战略，借助 EMAS 研发平台迈入移动开发 3.0 时代一、行业背景2019 年是中国银行业进入移动化时代的第 20 个年头：1999 年，在移动运营商的支持下，国内第一个手机银行上线，服务范围覆盖全国 26 个经济发达的重点城市。随后，各大银行相继推出基于手机短信和 WAP 网络服务的手机银行服务，开启了国内手机银行发展的第一个黄金十年。随着手机银行业务的不断丰富以及用户对手机银行体验、速度和功能的要求越来越高，传统的短信银行、WAP 银行已经不能满足用户的需要。与此同时，智能手机、3G 移动通信网络以及安全技术也在这十年间得到了飞速发展，2010 年开始手机银行进入了客户端（即手机银行客户端，以下简称 APP）时代，手机银行由此进入又一个飞速发展的十年。根据中国银行业协会的数据显示，截止到 2017 年，国内商业银行手机银行个人用户数量已达15.02 亿户，同比增长 28.28%；2017 年全年手机银行交易达 969.29 亿笔，同比增长 103.24%，交易金额 216.06 亿元，同比增长 53.7%。与其他国家相比，我国手机银行的发展时间虽然不长，但得益于我国飞速发展的移动互联网和移动支付，手机银行的市场环境和用户习惯基础极好。在我国，手机银行已经不仅仅是银行柜台业务或传统渠道的补充，而是成为了数字银行、智慧银行的重要承载，更促使我国银行业（尤其是中小银行）坚定的朝着移动化的方向发展。简介：可以想见，未来银行的绝大部分业务、渠道、连接点，都不免与手机银行打通，以实现线上、线下服务的无缝连接，并以此构建起新的银行形态。未来的手机银行将是银行产品创新、业务拓展和战略转型的重要平台，EMAS 移动研发平台已经为杭州银行打下了基础。3.EMAS 客户案例3.EMAS 客户案例“在 3.0 阶段，移动端的关键是体验，我们定义的 3.0 就是移动端服务体验的升级，与此同时，还要提升开发团队的知识和能力水平，让大约 50 人的移动端开发团队的开发经验能够互相支持、互助提高。”周炼表示，在 3.0 阶段，杭州银行选择与阿里云合作，以阿里云 EMAS 移动研发平台为基础，结合阿里巴巴在移动端开发领域的经验，提升杭州银行移动端的用户体验。三、开发平台慎重选型：EMAS 融入杭州银行长期移动化战略移动研发平台是企业移动化战略的基础，它不仅决定了企业移动端开发的效率、质量、成本、可靠性；更决定了企业是否能够及时、有效、符合需求的为最终客户提供移动化服务，支持传统线下业务向线上转化和传统 PC 服务向移动端转化。因此，企业移动研发平台的选型维度一般会有如下四个切入点：统一的研发管控平台：可以统一的管理开发、测试、构建、发布、性能监控、热修复等工作，在 APP 完整的生命周期中形成闭环；具备“一次开发，多平台运行”的能力：同时支持 Android 和 iOS 平台，无需重复开发，同时支持 H5、WEEX、原生等开发模式；完善、稳定的功能组件库支持，提高开发速度，加速开发进度，避免重复性开发底层、基础功能；移动接入网关，提供 API 管理、限流、MOCK 等功能，以及和后台服务的无缝对接；以上四个切入点同样得到了杭州银行的关注，杭州银行最初的移动研发平台诉求与此类似，也同样可以归纳为四点：1、具备打造跨平台、兼容性高的 APP 的能力，防止出现闪退等情况；2、具备快速更新的能力，可以在线更新（热修复），对于小代码量的补丁包可以做到无感更新；3、具备信息采集的能力，能够支持杭州银行的对客户反馈、客户使用情况的收集；4、要比原有 H5 有更好的效果，但也要避免大量的原生开发，既要保证客户（的原生 APP）体验，也要满足（类似 H5 的）开发上线速度的要求。经过详细的评估对比，杭州银行最终选择了 EMAS 作为其移动研发平台，同时首选在内部移动办公 APP 上开始落地：“杭州银行的内部移动办公 APP 并不统一，内部有多个 APP，这对行内人员的使用体验、使用效率和使用安全上都有影响，所以在 EMAS 移动研发平台上的第一阶段工作，我们希望把内部 APP 整合到一起服务行内人员，为内部移动办公提供更好的体验和更及时的问题处理。”3.EMAS 客户案例3.EMAS 客户案例产生了很大的帮助。”随着杭州银行内部移动办公 APP 升级为移动办公超级 APP，这一内部应用不仅很好的融合了过去 H5、WEEX 和原生应用的统一入口、统一接入，融合了包括公告，会议通知、工作动态、待办提醒、审批，CRM 等完整功能（比如说，行内人员在 APP 上统一认证登录后，即可访问行务公告、公文、会议通知、移动审批、你问我答、通讯录等应用），为行内人员提供了集中化的服务体验，同时对于开发团队来说，将原来已有的 APP 经过很简单的转换，就可以作为组件Bundle 接入超级 APP，极大的减少了内部移动办公 APP 融合的工作量。与此同时，由于 EMAS 提供了许多公共化的功能，杭州银行的开发团队不必再在用户登录等通用模块上投入太大精力，“我们不需要太多关注通用模块、开发框架，而是可以专注于做自己的业务开发、创新功能特点，团队的开发效率和开发专注度有很大的提高。”四、EMAS：从支持移动端开发到赋能移动开发团队EMAS 移动研发平台为杭州银行的移动办公系统转型升级移动办公超级 APP 提供了有效的支撑，但其所起到的作用却不仅仅局限于技术赋能，对于杭州银行来说，EMAS 移动研发平台的引入为移动开发团队自身的成长同样带来了新的价值。传统移动开发团队为了同时满足 Android 和 iOS 跨平台的开发需求，往往分为两个专项团队，这意味着即使是相同的功能，由于针对两个平台、分属两个团队，仍然需要进行重复开发，这不仅导致了极大的人力、物力、时间上的浪费，而且两个团队之间在开发技能、开发经验和安全体系上，也由此存在着差异和差距。随着采用 EMAS 移动研发平台，杭州银行可以通过 WEEX 技术实现跨平台开发，而且由于WEEX 在底层采用原生渲染，在性能和功能实现度上很接近原生开发，不仅客户应用体验几乎与原生 APP 毫无差别，而且将 Android 和 iOS 两个研发团队集中在一个平台上，实现基于 EMAS、面向 APP 功能（而不是跨平台或硬件兼容性）的合作开发，聚焦 APP 的具体功能、业务创新，特别是促进了开发团队成员之间的经验分享，避免了原有两个专项团队并立导致的“重复踩坑”的问题，也让开发人员在知识体系掌握方面更为全面。EMAS 移动研发平台的引入，让杭州银行的移动开发团队建立了一个“直通车式”的产品、技术人员对接体系，业务需求可以对接到人、精准反馈，客户问题可以精准定位，开发团队不再被APP 开发本身的技术问题占用大量精力，从而能够在提高业务开发能力、前瞻性技术开发上投3.EMAS 客户案例4.隐私保护政策下 EMAS 的产品升级4.隐私保护政策下 EMAS 的产品升级EMAS 发布最新隐私协议，为客户信息安全保驾护航公民个人信息不容侵犯，确保 APP 不“越界”，国家一直在行动。数据显示，近年来，工信部持续开展 APP 侵害用户权益的整治活动，开展了六批次集中抽检，检查了 76 万款 APP，通报748 款违规 APP，下架了 245 款拒不整改的 APP。友商案例以极光举例，是通过提供消息推送，即时通讯、统计分析、社会化组件和短信等开发者服务累计数据和标签，继而通过精准营销、金融风控、市场洞察和商业地理服务等数据业务进行变现。在南方都市报发表于2020年11月27日的文章中被指出存在使用违规收集个人信息的第三方组件的问题，此外腾讯、个推、小米 SDK（软件开发工具包），以及旧版本的 360 加固工具同样被揭露存在此类问题。阿里云数据隐私保护阿里云作为业界首家发起发起数据保护倡议的企业，数据隐私保护是阿里云的第一原则。隐私保护采取严苛的标准：全球首张云安全国际认证金牌（CSA-STAR）/亚洲合规资质最全的云服务商/全球第一张ISO/22301国际认证证书/第一家同时完成德国C5云安全基础要求和附加要求评审的云服务提供商/欧盟数据保护法规 GDPR/等保 2.0 四级。简介：公民个人信息不容侵犯，数据显示，近年来工信部持续开展 APP 侵权整治活动，开展了六批次集中抽检，检查了 76 万款 APP，通报 748 款违规 APP，下架了 245 款拒不整改的 APP。移动研发平台 EMAS 高度重视个人信息的保护，在客户使用 EMAS 服务时，将根据法律法规要求并参照行业最佳实践为客户个人信息安全提供充分保障。现 EMAS 最新隐私协议已发布，将全方面为客户的信息安全提供保障。4.隐私保护政策下 EMAS 的产品升级5.EMAS 旗下移动性能测试5.EMAS 旗下移动性能测试云上的移动性能测试平台1.功能决定现在，性能决定未来性能测试在移动测试领域一直是一个大难题，它最直观的表现是用户在前台使用 App 时的主观体验，然而决定体验优劣的背后，涉及到了许许多多的技术变迁。当我们习惯于诺基亚时，智能机出现了；当我们学会 native 开发时，hybrid 来了；当各种hybrid 框架下的巨型应用倾向成熟时，小程序出现在我们眼前；紧接着直播、iot、ar、vr、人工智能，新的技术与应用场景正在以无法想象的速度向前发展。性能测试技术在快速变化的场景与开发技术面前，面临着巨大的挑战，当我们还在纠结如何测试 a 时，b 就已经出来了。性能测试本身，有发展日渐成熟的解决方案，如线上性能监控 APM、线下性能采集工具；有基于各个应用场景衍生的测试技术，如压力测试、稳定性测试、功耗测试等；也有基于各项性能指标（内存、cpu、电量、流量）而来的各种专项测试能力。我们致力于打造线上线下一体的性能解决方案，希望能够帮助开发者发现、定位与解决一系列移动端性能问题。本文将着重介绍 EMAS 性能测试平台的能力与规划，还是那句话，功能决定现在，性能决定未来。2.云上的性能测试工具通常我们在进行专项测试（内存、cpu、电量、流量等）时，需要准备测试机型、测试包、测试环境、测试数据，会遇到以下问题：简介：功能决定现在，性能决定未来。欢迎大家围观云上的移动性能测试平台，了解 EMAS 性能测试平台的能力与规划。5.EMAS 旗下移动性能测试5.EMAS 旗下移动性能测试3.云上数据看板性能数据的意义在于它将我们常见的各种问题通过技术的手段进行度量与量化，可以帮助我们在产品功能上线前，尽可能的发现潜在的性能问题和风险。MQC 性能测试平台将存储于云上的数据，以尽可能多的维度可视化给用户，把好版本发布前的关口。3.1 任务用户使用云真机进行的每一次测试任务与性能数据，都会直接保存成测试任务，方便再次查看与确认历史数据。5.EMAS 旗下移动性能测试5.EMAS 旗下移动性能测试设备分级根据设备硬件性能打分，划分为高、中、低三个级别。由于不同等级机型对 APP 实际性能指标的影响较大，这个因子可以较大程度减少硬件性能对指标置信度的影响。应用版本对于性能指标来说，通常有三种问题判断标准：基于行业技术经验定义的基线指标，这通常是技术决策者基于用户体验、性能要求、大数据分析给开发提出的底线标准；同行业 APP 性能指标横向对比，学习行业内优秀的技术实现一直是互联网快速发展的重要原因之一；同 APP 不同版本间的纵向对比，快速的发现新版本的优化效果，新功能对 APP 的影响等。指标分布指标分布可以帮助开发者快速判断指标区间，定位可能的异常任务与异常指标区间，更加有针对性的去查阅任务报告。5.EMAS 旗下移动性能测试6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景什么是低代码（Low-Code）？作者|阿里云 云原生应用研发平台 EMAS 彭群（楚衡）一、前言如果选择用一个关键词来代表即将过去的 2020 年，我相信所有人都会认同是“新冠”。疫情来得太快就像龙卷风，短短数月就阻断了全世界范围内无数人与人之间的物理连接。但好在，我们已经全面迈入互联网时代：N95 口罩再厚，也阻挡不了信息比特流的顺畅流通（宅男：B 站依然香）；居家隔离再久，也妨碍不了钉钉消息的准时送达（社畜：工作依然苦）。逍遥子在 9月份的云栖大会上说：“新技术代表的新生产力，一定是我们全速战胜疫情、开创未来最好的原动力。”那么在后疫情时代，究竟需要什么样的新技术，才能真正解放 IT 生产力，加速社会数字化转型，Make The World Great Again？我认为是低代码（Low-Code）。基于经典的可视化和模型驱动理念，结合最新的云原生与多端体验技术，低代码能够在合适的业务场景下实现大幅度的提效降本，为专业开发者提供了一种全新的高生产力开发范式（Paradigm Shift）。另一方面，低代码还能让不懂代码的业务人员成为所谓的平民开发者（Citizen Developer），弥补日益扩大的专业人才缺口，同时促成业务与技术深度协作的终极敏捷形态（BizDevOps）。本文将重点介绍低代码相关背景知识，包括低代码的定义与意义、相关概念、行业发展等，期望能帮助大家更好地认识与理解低代码这个新兴领域。二、什么是低代码“Low-Code”是什么？如果你是第一次听说，没准也会跟我当年从老板口中听到这个词后的内简介：什么是低代码？我们为什么需要低代码？低代码会让程序员失业吗？本文总结了低代码领域的基本概念、核心价值与行业现状，带你全面了解低代码。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景相比 Wiki 的版本，这个定义更偏向于阐明低代码所带来的核心价值：低代码开发平台能够实现业务应用的快速交付。也就是说，不只是像传统开发平台一样“能”开发应用而已，低代码开发平台的重点是开发应用更“快”。更重要的是，这个快的程度是颠覆性的：根据 Forrester 在 2016 年的调研，大部分公司反馈低代码平台帮助他们把开发效率提升了 5-10 倍。而且我们有理由相信，随着低代码技术、产品和行业的不断成熟，这个提升倍数还能继续上涨。低代码开发平台能够降低业务应用的开发成本。一方面，低代码开发在软件全生命周期流程上的投入都要更低（代码编写更少、环境设置和部署成本也更简单）；另一方面，低代码开发还显著降低了开发人员的使用门槛，非专业开发者经过简单的 IT 基础培训就能快速上岗，既能充分调动和利用企业现有的各方面人力资源，也能大幅降低对昂贵专业开发者资源的依赖。低代码核心能力基于上述的定义和分析，不难总结出如下这 3 条低代码开发平台的核心能力：全栈可视化编程：可视化包含两层含义，一个是编辑时支持的点选、拖拽和配置操作，另一个是编辑完成后所及即所得（WYSIWYG）的预览效果。传统代码 IDE 也支持部分可视化能力（如早年 Visual Studio 的 MFC/WPF），但低代码更强调的是全栈、端到端的可视化编程，覆盖一个完整应用开发所涉及的各个技术层面（界面/数据/逻辑）。全生命周期管理：作为一站式的应用开发平台，低代码支持应用的完整生命周期管理，即从设计阶段开始（有些平台还支持更前置的项目与需求管理），历经开发、构建、测试和部署，一直到上线后的各种运维（e.g.监控报警、应用上下线）和运营（e.g.数据报表、用户反馈）。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景平台的职责与挑战上面说的是低代码给开发者提供的能力与吸引力，那么作为服务的提供方与应用的承载者，低代码开发平台自身应该承担怎样的职责，其中又会遇到多大的挑战？是否就一定要如阿里云所主张的那样，“把复杂留给自己，把简单留给别人”？虽然这句话听起来很深明大义，但不知道大家有没有想过，为什么我们一定要抱着复杂不放，平白无故给自己找事？就不能直接干掉复杂，也给咱阿里云自己的员工留点简单吗？是工作太容易就体现不出来 KPI 价值了，还是家里的饭菜不如公司的夜宵香？冥思苦想许久后，我从热力学第一定律中找到了答案：开发一个应用的总复杂度是恒定的，只能转移而不可能凭空消失。要想让开发者做的更少，安心享受简单的快乐，那么平台方就得做的更多，默默承担尽可能多的复杂度。就像一个满身腱子肉的杂技男演员，四平八稳地托举着在高处旋转与跳跃的女搭档；上面的人显得越轻盈越毫不费力，下面的人就得越稳重越用尽全力。当然，不是说上面的女演员就很轻松没压力，只是他们各自的分工不同，所承担的复杂度也不一样。根据人月神话作者 Fred Brooks 的划分，软件开发的复杂度可以划分为本质复杂度（Essential complexity）和偶然复杂度（Accidental complexity）。前者是解决问题时固有的最小复杂度，跟你用什么样的工具、经验是否丰富、架构好不好等都无关，而后者就是除此之外在实际开发过程中引入的复杂度。通常来说，本质复杂度与业务要解决的特定问题域强相关，因此这里我把它称为更好理解的“业务复杂度”；这部分复杂度不是任何开发方法或工具能解决的，包括低代码。而偶然复杂度一般与开发阶段的技术细节强相关，因此我也相应把它称为“技术复杂度”；而这一部分复杂度，恰好就是低代码所擅长且适合解决的。为开发者尽可能屏蔽底层技术细节、减少不必要的技术复杂度，并支撑其更好地应对业务复杂度（满足灵活通用的业务场景需求），这是身为一个低代码开发平台所应该尽到的核心职责。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景低代码就像是现代的“视频”，大部分内容都由直观易理解、表达能力强的图片组成，因此更容易被大众所接受。但与此同时，视频也不是死板得只能有图片，完全可以添加少量文字（如字幕、标注）来弥补图片表达不够精确的问题。BTW，关于“图”和“文字”之间的辩证关系，可以进一步参考架构制图：工具与方法论1这篇文章中的相关描述。纯代码则更像是传统的“文章”，虽然很久以来都一直是信息传播的唯一媒介，但自从视频技术诞生以及相应软硬件基础设施的普及以来，便逐渐开始被抢走了风头。如今，视频已成为大部分人获取信息的主要渠道（从电视电影到 B 站抖音），而经常读书读文章的人却越来越少。但不可否认的是，文章依然有它存在的意义和受众（不然我也不会费这劲敲这么多字了），即使“市场份额”一直在被挤压，但永远会有它立足的空间。如果按上面这种类比关系推导，低代码未来也会遵循与视频类似的发展轨迹，超越纯代码成为主流开发模式。Gartner 的预测也表达了相同的观点：到 2024 年，所有应用程序开发活动当中的 65%将通过低代码的方式完成，同时 75%的大型企业将使用至少四种低代码开发工具进行应用开发。但同样地，就像是视频永远无法取代文章一样，低代码也永远无法彻底取代纯代码开发方式。未来低代码和纯代码方式将以互补的形态长期共存，各自在其所适合的业务场景中发光发热。在后面的“低代码业务场景”章节，会详细列出哪些场景在现阶段更适合用低代码模式开发。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景虽然零代码与狭义上的低代码有着上述明显差异，但从广义上来说，零代码可以当作低代码的一个子集。Gartner 在其相关调研报告中，就是将“No Code”划在了范围更广的低代码应用平台“LCAP”（Low-Code Application Platform）中。而当前市面上很多通用的低代码开发平台，也都兼具一定程度的零代码能力；比如低代码领域领头羊 Mendix，既提供了简单易用的零代码 Web IDE-Mendix Studio，也包括一个功能更强大的低代码桌面 IDE-Mendix Studio Pro。HpaPaaS（高生产力应用 PaaS）上文提到，“Low-Code”一词是拜 Forrester 所赐。作为同样是国际知名调研机构（a.k.a 造词小能手）的 Gartner，显然不会轻易在这场可能决定低代码领域江湖地位的新概念作词大赛中认输，于是也于 2017 年发明了“HpaPaaS”（High-productivity application Platform as aService）这个听上去更高大上的缩写词。按照 Gartner 的定义，HpaPaaS 是一种支持声明式、模型驱动设计和一键部署的平台，提供了云上的快速应用开发（RAD）、部署和运行特性；这显然与低代码的定义如出一辙。但事实证明，名字起得太专业并不见得是好事，“HpaPaas”最终还是败给了起源更早、更接地气也更顺口的“Low-Code”：从 2019 年开始，Gartner 在其相关调研报告中也开始全面采用“Low-Code”一词（如 LCAP），亲手为“HpaPaaS”打上了 deprecated 印记。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景也正面临着与我国社会主义初级阶段类似的供需关系矛盾：落后的软件开发生产力跟不上人民日益增长的业务需求。Gartner 预测，到 2021 年应用开发需求的市场增长将至少超过企业 IT 交付能力的 5 倍。面对如此巨大的 IT 缺口，如果没有一种革命性的“新生产力”体系，很难想象仅凭现有传统技术体系的发展延续就能彻底解决问题。而低代码技术正是带着这样的使命而降临，期望通过以下几个方面彻底革新应用开发生产力，拯救差一点就要迈入水深火热的 IT 世界：提效降本&质量保障虽然软件行业一直在高速发展，新的语言、框架和工具层出不穷，但作为从业者我们不得不承认：软件开发仍处于手工作坊阶段，效率低、人力成本高、质量不可控。项目延期交付已成为行业常态，而瓶颈几乎总是开发人员（对机器能解决的问题都不是问题）；优秀的开发人才永远是稀缺资源，还贼贵；软件质量缺陷始终无法收敛，线上故障频发资损不断。相比而言，传统制造业经过几百年工业革命的发展，大部分早已摆脱了对“人”的强依赖：从原料输入到制品输出，中间是各种精密仪器和自动化流水线的稳定支撑，真正实现生产的标准化和规模化。虽然信息化号称是人类的第三次工业革命，但以软件行业目前的状况，远远还没到达成熟的“工业化”阶段。6.EMAS 旗下低代码 mobi 产品背景6.EMAS 旗下低代码 mobi 产品背景至此，应用开发能力不再是少数专业开发者的专利和特权，且今后所需要的技能门槛与拥有成本也会越来越低，真正实现所谓的“技术民主化”（democratization of technology）。加强开发过程的沟通协作多方调查结果显示，软件项目失败的最主要原因之一就是缺乏沟通（poor communication）。传统开发模式下，业务、产品、设计、开发、测试与运维人员各司其职，且各有一套领域内的工具和语言，长久以来很容易形成一个个“竖井”（silos），让跨职能的沟通变得困难而低效。这也是为什么当前热门的敏捷开发和 DevOps 都在强调沟通（前者是协同 Biz 与 Dev，而后者是协同 Dev 和 Ops），而经典的 DDD 领域驱动设计也主张通过“统一语言”来减少业务与技术人员之间的沟通不一致。有了低代码后，这一状况将得到根本改善：上述各角色都可以在同一个低代码开发平台上紧密协作（甚至可以是同一个人），这种全新的协作模式不仅打破了职能竖井，还能通过统一的可视化语言和单一的应用表示（页面/数据/逻辑），轻松对齐项目各方对应用形态和项目进度的理解，实现更终极的敏捷开发