数字化创新浪潮之下，微服务架构已经被越来越多的企业采用。本文通过网易云轻舟微服务核心研发人员的实践总结，解读如何建设微服务基础设施，以便更好地利用微服务技术来支撑业务实现跃进式的发展。在本篇中，网易云架构师、轻舟微服务技术负责人冯常健结合网易云实践总结了微服务的沿革、价值、落地挑战和解决思路，并分享了网易云打造轻舟微服务的核心经验，以及未来的技术路线。

（网易云架构师、轻舟微服务技术负责人冯常健）

冯常健认为，微服务化是分布式架构发展的高级阶段，是目前满足大规模业务、高速迭代、高可用率等需求的最优方案。他介绍，网易云轻舟微服务平台的成功研发，为网易公司完善各个业务中台打下了基础，产品研发效率提升100%，部署效率提升280%；也成功应用于物流、制造、银行、证券等行业，帮助客户快速实现微服务化以提高生产力，包括一年节省超过千万元的研发运维成本。

网易云是如何做到的？冯常健表示，实施微服务涉及分布式架构的多种挑战，技术门槛高，众多开源组件可以满足企业建设微服务基础设施的基本需求，但开源组件学习成本高，配置复杂，且应用侵入性大，网易云以基于开源、无侵入、易用性为设计原则，基于多年技术积累，将复杂的微服务技术封装为通用平台，帮助业务团队快速、低成本地实现架构微服务化，并提供一整套工具链，包括服务治理、DevOps、AIOps、自动化测试等，保障微服务业务系统顺畅运行。

轻舟微服务诞生：稳定性、扩展性和开发效率的召唤

2012年，冯常健加入网易杭州研究院，开始了云计算研发的工作。初期他主要参与和负责云管平台、云消息队列、自动化部署平台等云服务设计与开发，目前这些云服务在电商、音乐、教育、传媒等部门都有广泛应用。通过这些项目，他对云计算的整个技术栈，以及如何设计一个云服务有了深刻认识，也逐渐形成了设计分布式系统时的思考习惯： 首先会从可用性、稳定性、性能、扩展性等非功能特性入手设计或者review架构的合理性。

从2015年开始，伴随着Docker和Kubernetes的流行和项目需要，冯常健开始转向容器技术的应用研究，之前的自动化部署平台核心在于解决应用构建与部署问题，而在资源编排、服务编排、服务故障自愈等在DevOps实践中同样重要的问题则较少涉及，而容器技术可以补齐自动化部署平台缺少的这些能力，通过容器技术提供的弹性伸缩、服务编排、错误恢复等能力，结合IaaS提供的资源可编排能力，实现无服务器（Serverless）形态的容器平台。

容器技术的普及，推动了微服务架构在网易内部的广泛应用。爆发式增长的网易业务，遇到低耦合、易扩展的微服务，可谓干柴烈火，容器平台则是火上加油。微服务通过业务拆分、进程独立部署、轻量化的通信方式等手段解决了单体架构中存在的可用性、稳定性和扩展性差等难题，并使得团队有更多的技术栈可以尝试，减少团队沟通成本，提升开发效率，加快迭代速度。而容器的镜像和编排等能力，则成为了微服务细粒度分拆与优雅协作的神器。

在两年多的容器和微服务实践中，网易云验证了基于Kubernetes的容器平台在微服务架构的部署调度、集群容错、故障恢复等方面的彪悍实力，也发现了平台还有一些亟待优化的问题，比如服务注册发现、流量负载均衡、服务熔断降级、配置管理等，虽然Kubernetes对这些问题也有相应的解决方案，但在生产环境落地时，一些客户比较担心这些方案的性能、稳定性和可运维性。引入基于Spring Cloud的微服务治理框架，是否能更好地解决服务运行时治理等问题？

于是，冯常健和他的团队在2017年开始了轻舟微服务框架组件的研发，希望新的微服务框架可以和容器平台以及云计算部门研发的DevOps、APM、自动化测试等组件形成互补，形成端到端的轻舟微服务平台，更好地支持微服务落地。

在网易公司内部，轻舟微服务帮助完善了各个业务中台的建设，产品迭代最高提速100倍，人力运维成本节省80%，单节点20,000个服务实例同时在线及水平扩展的支持，让电商大促扩容更加顺畅。而对于企业客户，轻舟微服务也意味着数字化创新的核心平台之一，某客户直接采用轻舟微服务，大幅提升按需扩容响应速度，上线部署时间缩短80%，研发周期缩短40%，并省去交付沟通、协调等成本，成本节省折合货币效应超过千万元。如果自己研发这个平台，至少需要投入30人团队，耗费半年时间。但该公司认为，更重要的是基于轻舟微服务能够灵活地进行业务调整，此前需要半年才能上线新业务，现在只需要一个月。

微服务技术挑战：本质是分布式架构的挑战

在冯常健看来，上述成果的实现，得益于对架构本质的把握，而实现微服务的挑战，本质上还是分布式架构带来的挑战。一旦实施微服务架构，团队会面临服务注册、服务发现，服务流量的负载均衡，分布式系统的集群容错、系统的可用性和可扩展性，服务数量多了之后的配置管理、部署调度，还有如何进行日志和监控的统一管理、如何进行服务调用跟踪等等。这些挑战，每一项都需要引入大量的基础技术平台和框架组件来解决。

当然，每一项挑战也都有不少开源解决方案。从实施微服务的技术团队角度来看，团队可能喜欢一开始就引进很多新技术，设计出一套能满足未来3到5年的架构出来，但从业务的角度来看，其实不是每一个阶段都有必要引入这些技术实现或解决方案，在人力有限的情况下，如果团队把太多精力倾斜在微服务架构建设方面，忽视了承载更多价值的业务研发，这就是本末倒置，最终可能会导致项目的失败。

冯常健解释说，业界常见的开源解决方案，比如对于Java技术栈，有Dubbo和Spring Cloud框架，都很强大，但它们的学习曲线比较陡峭，而负责每个微服务的往往是相对比较小的团队，如果其中大部分人再把时间都放在新技术、新框架的学习上，团队就没时间投入到业务开发。以Spring Cloud为例，如果每个团队上来都要学习几十个组件，而且学完了也不一定能用好它们，对开源组件掌控程度不够反而会给业务带来一些不稳定的因素，这对于企业而言也是很大的成本。所以，不能为了做微服务而做微服务，而是要根据业务匹配度来选择技术。

轻舟微服务框架设计：基于三大原则

对于网易云而言，容器平台和DevOps工具链已经就绪，APM也有基础，解决上述问题，核心便是微服务框架的研发，而作为云计算技术提供商的网易云，却必须考虑产品能力的全面性。那么，网易云又是如何思考和实践的呢？冯常健介绍，团队在微服务框架设计上定义了三大原则。

首先是基于开源技术栈，整个架构基于Spring Cloud，兼容Dubbo，以插件化的方式实现服务注册发现、服务治理、负载均衡、流量控制等。基于来源、兼容开源，可以最大程度地降低客户了解产品、使用产品的成本。

其次是无侵入性，实现了微服务治理框架和用户业务的松耦合，好处是用户只需要关注业务，服务治理框架的引入和升级不会带来业务改造的成本。插件化的方式，有利于实现这一点，并且对服务性能的影响可以忽略。

第三是易用性，实现图形化的统一控制中心，通过一个平台化界面涵盖完整的实时的服务治理能力，将用户从繁琐的配置中解放出来，允许用户通过图形化界面解决原本需要编写代码、编写配置才能解决的问题。

这些设计要求在技术实现上存在很大的技术挑战。例如无侵入性的实现，轻舟微服务主要采用Javaagent字节码增强技术，将服务治理逻辑以独立Jar包的方式提供加载。为支持更大的并发，轻舟微服务后端采用全分布式架构，能支持单节点20,000个服务实例同时在线，支持水平扩展，并提供99.99%以上的可用性。

目前，在微服务框架模块上，轻舟微服务已经实现了服务注册发现、负载均衡、集群容错、服务熔断降级、流量控制、动态配置管理、统一监控大盘等能力，覆盖了微服务的治理到问题的定位和排查。

性能优化对轻舟微服务框架而言也是重要的工作。例如，对Spring Cloud社区的服务发现组件Eureka做了源码级的定制和参数优化，实现了单节点10,000个服务实例的注册能力。同时，还引入异步化框架，比如Servlet 3.0、异步HttpClient、Disruptor等技术，使得轻舟微服务的请求转发能力达到单节点30,000以上TPS，并且延迟控制在5毫秒以内。

正是这些优化工作，让轻舟微服务能够承担重任，满足了网易内部和网易云客户的业务需求，实现了微服务的价值。

轻舟微服务的未来：融合Service Mesh

当前社区热议的下一代微服务架构Service Mesh，也是网易云轻舟微服务在未来微服务框架方面的工作重点。冯常健认为，Service Mesh提供的通信方式，更安全、快速和可靠，控制面与数据面的设计，使得微服务治理功能与业务解耦更加彻底。

目前开源Service Mesh架构实现中，控制面有Google主导的Istio，数据面有Envoy、Linkerd等，都是已经或者即将进入CNCF（云原生计算基金会）的开源组件，轻舟微服务框架秉承基于开源、兼容开源的思想，通过集成开源技术能力去帮助用户更好落地微服务。

轻舟微服务目前在Service Mesh方向的工作有两方面，一方面是基于Envoy做优化和改进，提供高性能的微服务通信网络，形成自己的数据面组件，可无缝对接轻舟微服务控制平台。另一方面，Istio目前的发布版本是基于Kubernetes实现的，无法脱离Kubernetes容器平台运行，而轻舟微服务框架定位是底层基础设施平台无关的，它不关心服务是运行在容器里面，还是直接运行在虚拟机、物理机上。因此，轻舟微服务框架集成Istio会是一个工作重点。

点击了解网易云轻舟微服务，获取方案  

图片来源@视觉中国

文 | 新眸，作者｜鹿尧

当企业把数字化转型提上日程时，最先意识到的往往是战略需求，而不是业务要求。随着转型由浅入深，速度和质量决定了生死，这时候才发现现有的开发工具与开发方式，管理水平及人才配备，其实很难胜任新的生产需求。

之前有数据统计，从转型成功率上看，信息化程度较高的行业小于26％，而传统行业只在4％~11%区间。为了解决这个问题，行业里常规的逻辑，企业如果要真的跨越周期，必须先使用合适的新工具，无论是云计算、Serverless、各种Xaas，目的都是为了理想化的降本增效，低代码也是同样的道理。

Gartner认为，未来企业间互动、需要更多的设备接入，业务会更加分散，专业开发者的数量并不足以满足企业IT需求。供需矛盾间，可视化+拖拉拽的低代码平台能让所谓的平民开发者，即普通的业务人员也能进行应用搭建，成为平台的最终用户，写更少的代码，花更少的钱，干更多的事，这看起来非常诱人，而且蕴含了巨大的商业前景。

2018年是一个有趣的节点，随着OutSystems成为超过10亿美元的新晋独角兽，低代码概念也被大量曝光，国内低代码赛道在近几年也尤为火热。

中国低代码行业投融资事件汇总图源前瞻产业研究院

之后，从2019年阿里把内部产品宜搭正式对外商用，到两年后发布低代码开发聚合平台“钉钉搭”，腾讯上线微搭，华为有AppCube，百度有爱速搭，大厂之外，传统ISV躬身入局，一大批创业型选手也纷纷涌现。相比国内，国外巨头的布局更早，微软、谷歌、亚马逊都将低代码看作未来，也都拥有自己的低代码平台：PowerApps、Honeycode和Appsheet。

理想的状态是，低代码能将所有与应用开发相关的活动，都收敛到同一个平台，从而产生更多方面的聚合效应与规模收益，但事实的发展却并不顺利。

站在2022年这个节点上会发现，同为企业服务里的细分赛道，虽然近年来跑出不少低代码玩家，但既没有产生像erp里的用友、金蝶，更遑论crm领域的salesforce以及协同办公里的zoom。反而传出的更多是被收购的消息，比如西门子收购Mendix和TimeSeries、Magic收购PowPow、字节收购黑帕云。考古微软2005年开始投入的webform，InfoPath等工具，也早被时代淘汰，现在一些寄生大厂生态的明星厂商，名声并没有如雷贯耳。

愿景是美好的，不过现实中类似“低代码是不是伪需求、是否能真的商业化”的质疑声也一直不断，尽管理论上降低了开发门槛，但怎样让客户真正用起来，低代码还是难以实现纯粹的产品化推动。平台如果预设是代码小白，牺牲上限换短期效率，不仅会限制平台成长，是否真的增效也不一定；如果提供给专业开发者，作用又难免鸡肋，更不必说昂贵的变革成本。

为什么低代码里至今没有keyman，归根结底，这并不仅是战略层面拍脑袋能解决的问题，除了开发阶段，还要考虑产品的全生命周期，如果将价值认定框在降本增效的标准里，其实不太符合现实商业原则；数字化转型的过程中，风很大，具体到产品、市场、业务、用户、特定的应用场景，有太多的细节需要重新考虑。

01 厂商看技术，甲方看业务

模块化、可视化的编程方法由来已久。20多年前，微软的Visual Basic、Access以及Sybase PowerBuilder、Delphi Builder等编程工具风靡一时，都算作比较早期的低代码工具，多年来热度起起伏伏，很多人认为，如今不过是用“低代码”这个新瓶，装了表单、工作流、业务对象等旧酒，包装成面向业务应用层的低代码平台，本质仍是个OA自定义表单和自定义流程引擎而已。

到2020年左右，广义上的低代码开发平台包含低代码与无代码，前者面向程序员，后者提供给没有编程基础的业务人员，用友副总裁罗小江认为，“3-5年内可能低代码平台主要还是针对专业开发者，混合开发模式能够简化一些基础问题，程序员在此基础上做复杂开发。”低代码的成熟度，还停留在需要技术人员在一线业务员和开发商间做沟通的程度。

实际上，现在对于低代码的各种技术界定、渲染的实际意义不大，它的核心是为了解放生产力，那么业务逻辑比开发逻辑更重要。低代码之所以受市场追捧，源于数字化转型阶段的业务与产品供需矛盾。

当深入到具体业务会发现，现在的商业链条很复杂，比如从供货端、各种营销渠道，到各个电商平台推广卖货，现有的进销存软件并不能整合管理从收集订单、组织生产，到调派库存发货的不同平台订单数据，也不能分析销售情况进行客户追踪。

于是，有预算的企业想要自己开发软件，但在需求、交付时间、质量都不可控的情况下，供需问题短期内很难解决。回到一开始，任何的企业软件都只是技术手段，技术最终要解决的是业务和管理的问题。所以，真正要讨论的就变成了低代码是否真的好用，商业化落地是否可行。

比如在C端，消费者的需求千变万化，供应商是很难靠卖纯粹低代码平台来赚钱，加上用户的产品认知度不高，市场教育成本不容忽视；为了维持基础能力，要兼顾定制的灵活性和运行的高性能，因为使用的人越多，边际成本才越低，这些对一般初创厂商来说压力山大。

如果在B端，考虑是否真的给企业客户降低了成本，并且满足个性化需求，这意味着企业结果导向。市面很多产品都是固定化流程设计，功能缺失或冗余难以避免，比如当你买了一个进销存系统，但当想统筹管理人员绩效时，就得去买另一个，这种情况下的理想场景是，企业人员能够按需自行设计多场景系统，听起来似乎更实用。

大企业的业务流程、数据逻辑往往按照业务规范去做，低代码平台加上成熟的解决方案，可以更快捷地搭建；但受限于服务能力边界，低代码有明显的天花板，它无法替代当下的中、高级开发工作需求。中小企业的使用意愿也会被高估，即使用轻量化场景来，满足这些业务逻辑更简单的企业，除了搭建成本，还要因为业务不规范的“削履适足”，低代码反而不容易应对。

现阶段，不论在C端还是B端，在业务还没有实现标准化，数据也没建立标准时，低代码平台都不可能满足任意复杂度的业务，这也让它的应用场景被局限在那些只能被标准化的领域里，完成业务的全面覆盖更不现实，还会对企业的数据治理、信息安全产生隐患。

敏捷、普适、丰富的场景、性价比高，这是每一个低代码厂商在宣传自家产品时会用到的ppt话术，也是资本喜闻乐见的故事。不过作为入局者，钉钉、用友和简道云的相关负责人都曾表示，低代码市场的宣传是有些言过其实的，拓荒的过程很艰难，目前的渗透率极低，在所有的行业里渗透率基本上都是个位数，甚至仅仅1%、2%。

中国低代码市场渗透率低图源洞见研报

在数字化浪潮中，RPA赛道的玩家们也正在经历类似的事情。由于低代码环境弱化编程需求，RPA市场边际扩大，并被认为是全球增速最快的细分软件市场，仅今年上半年，以达观数据、影刀为代表的国内RPA厂商累计融资金额达20亿，相关企业注册量接近400家。

但相较国外各领域对RPA的应用已经成熟，比如UiPath虽然验证了商业模式和落地场景的可行性，但国内的厂商仍在找试验田，具体到哪些业务流程适用RPA机器人，产品应用范围、边界及周期怎么定，市场还未实现规模化验证。加上产品功能的单一同质等问题，以至于国产RPA厂商客户年流失率平均在30%，远高于国外。

低代码和RPA的高开低走，其实不难理解，我们很多时候对于一个新兴概念的热捧，要远高于产品彼时存在的实际价值，即使它被认为是发展潜力巨大的风口，但在早期阶段，缺乏本土市场验证的情况下，产品是没有普适性的，更不是企业用来加速适应市场的“万能药”，与其忽视市场的复杂去盲目照抄，或者积极炒作甚至削足适履，都不如在适当的阶段做恰当的事更合时宜。

02 从低代码平台到生态

今年上半年，低代码厂商黑帕云正式停服，从被资本热捧到被字节收购，黑帕云是赛道热潮中首个退出的玩家，这件事也被看作国内低代码行业洗牌的开端。

低代码厂商图谱图源艾瑞咨询

在停服之前，有人评价黑帕云是综合能力最好用的轻量级数据协作工具。刚上手的时候可以直接当作Excel用，但它本身不仅比Excel更容易理解且支持协作，数据保存的完整性上也表现不错；接着在使用过程中加深对业务理解进一步升级业务系统，也就是说，软件本身并不是最重要，对业务和数据的理解、从而让业务系统不断生长的过程才是最重要的。

收购后不久关停，有人将原因归为飞书的核心产品多维表格，后者功能与黑帕云类似，虽然字节在低代码领域行事低调，但多维表格本身也是低代码的一个体现。飞书向来采取all in one 的策略，大客户的需求大多由飞书自己来做，随着业务的深化，用低代码去满足海量需求可以算是布局未来。

互联网巨头都在低代码领域加紧布局，像黑帕云的例子并不鲜见，虽然小企业的品牌变现能力对于大厂来说并不诱人，但沉淀下来的核心技术、产品理念和经验的确是有价值的。这也反映出，在本身冲突就很多的低代码赛道，走中小客和PLG增长这一路线的小团队，想要实现商业变现难上加难。

阿里的思路不太一样，在赛道之外，低代码起着“连接”和“高效办公”的作用。草蛇灰线，从2019年张勇首提“商业操作系统”，希望帮助企业实现品牌、商品、销售、营销、渠道管理、物流供应链等多环节的数字化；次年，钉钉升级为大钉钉事业部，并融入阿里云智能事业群，钉钉成了云服务的平台。

钉钉推出的低代码开发聚合平台”钉钉搭”，聚集了宜搭、简道云、氚云、轻流在内的8款主流低代码厂商，金蝶、用友、纷享销客等也是钉钉生态一员。与其说是细分赛道里的低代码平台厂商，钉钉更像一款协作办公平台，基于协同密度来建设应用生态，这样一来，对原有的存量系统服务，面对复杂且分散的业务，钉钉起到连接器和整合的作用。

同一时期，用友完成ERP到BIP，从产品服务模式升维到平台服务模式。2020年发布的低代码平台YonBuilder为用友自身、伙伴、客户的应用开发提供统一开发输出的能力，帮助用友BIP实现商业落地。YonBuilder的存在和后来加入的APICloud，完善了用友的服务链条，和钉钉主打平台及应用生态不同，用友侧重开发者生态和低代码产品。

在传统软件转云的厂商，和互联网玩家纷纷进军低代码的情况下，构建生态成为共识，意味着现阶段很难出现直接对标Airtable、Notion的独立产品。这类似曾经国内爆火的BI赛道，随着大厂BI产品销声匿迹，大部分独立BI厂商以被收购、退出市场或抱团取暖收尾。同样作为一种辅助性工具，从狭隘的定位上，低代码是否会重蹈覆辙还需观望。

03 比起开发，说搭建更合适

如果打开知乎搜索低代码，会发现很多人的字里行间不乏抱怨。“别的不说，单就工作量是一点都没有减少，反而平添了很多很多的麻烦，不用‘低代码’平台分分钟就能开发出来的功能，用了之后得花更多的时间。”

因为目前大部分低代码平台都是高度封装，高度耦合的开发模式，所有功能必须得按照平台既定的规则开发,假如只是简单的增删改查，导入导出，聘一堆薪资不高的外包去用低代码写重复度高的业务，那确实是没有问题。一旦遇到客户有类似五彩斑斓的黑的要求，平台现有的功能又无法满足，很多人连Excel都不会用，更别提改代码，最后只能是做开发的人来返工。

虽然不论是Gartner还是IDG，市场都对低代码的未来表现高度热情，但局中人冷静发言，“它既不是模式的问题，也不是资本问题，而是赛道问题。低代码产品好像什么需求都能做，但是好像每种需求又做不好。”简道云联合创始人单兰杰认为，低代码最大的问题，是这种产品形态怎么能够持续地满足客户需求。

确实是这样，低代码可能会是程序员的一把工具，但不会成为颠覆行业的东西。正如前言，同为企业服务里的细分赛道，低代码这一支尤其分散，看似每一项业务都能适配，但实际的业务用途目前还是狭窄，大多限于简单的行政类、人事类需求，例如工作流和表单流转，大软件的部分功能延伸，面向企业用户的快速补充开发。企业的核心业务如生产、销售、采购库存等，还是要用传统的erp，这些很难用低代码去实现。

它的出发点是好的，我们倾向认为低代码弥补中小企业开发人员数量上的不足，但开发是一回事，能用起来是另一回事。低代码能力是否会变成一个与Office套件一样普及的基本办公职业技能，尚不可知；未来是继续加功能，还是开放更多的接口，做交付动作满足需求，还是产品保持简洁，通过一些其他模块，或应用市场的方式去解决问题，这些也不好回答。

编者：本文作者为携程基础业务研发部-数据智能应用组研发负责人董锐。董锐有近9年的互联网从业经验。2013年1月加入携程，曾在商业智能部设计和开发基于HADOOP生态体系的大数据数据仓库。现任基础业务研发部-数据智能应用组研发Leader，专注于携程个性化推荐系统，ABTEST等系统研发工作。

————————————————————

互联网二次革命的移动互联网时代，如何吸引用户、留住用户并深入挖掘用户价值，在激烈的竞争中脱颖而出，是各大电商的重要课题。通过各类大数据对用户进行研究，以数据驱动产品是解决这个课题的主要手段，携程的大数据团队也由此应运而生；经过几年的努力，大数据的相关技术为业务带来了惊人的提升与帮助。

以基础大数据的用户意图服务为例，通过将广告和栏位的“千人一面”变为“千人千面”，在提升用户便捷性，可用性，降低费力度的同时，其转化率也得到了数倍的提升，体现了大数据服务的真正价值。

在新形势下，传统应用架构不得不变为大数据及新的高并发架构，来应对业务需求激增及高速迭代的需要。

一、业务高速发展带来的应用架构挑战

公司业务高速发展带来哪些主要的变化，以及给我们的系统带来了哪些挑战？

1）业务需求的急速增长，访问请求的并发量激增，2016年1月份以来，业务部门的服务日均请求量激增了5.5倍。

2）业务逻辑日益复杂化，基础业务研发部需要支撑起OTA数十个业务线，业务逻辑日趋复杂和繁多。

3）业务数据源多样化，异构化，接入的业务线、合作公司的数据源越来越多；接入的数据结构由以前的数据库结构化数据整合转为Hive表、评论文本数据、日志数据、天气数据、网页数据等多元化异构数据整合。

4）业务的高速发展和迭代，部门一直以追求以最少的开发人力，以架构和系统的技术优化，支撑起携程各业务线高速发展和迭代的需要。

在这种新形势下，传统应用架构不得不变，做为工程师也必然要自我涅槃，改为大数据及新的高并发架构，来应对业务需求激增及高速迭代的需要。计算分层分解、去SQL、去数据库化、模块化拆解的相关技改工作已经刻不容缓。

以用户意图（AI 点金杖）的个性化服务为例， 面对BU业务线的全面支持的迫切需要，其应用架构必须解决如下技术难点：

1）高访问并发：每天近亿次的访问请求；

2）数据量大：每天TB级的增量数据，近百亿条的用户数据，上百万的产品数据；

3）业务逻辑复杂：复杂个性化算法和LBS算法；例如：满足一个复杂用户请求需要大量计算和30次左右的SQL数据查询，服务延时越来越长；

4）高速迭代上线：面对OTA多业务线的个性化、Cross-saling、Up-saling、需满足提升转化率的迫切需求，迭代栏位或场景要快速，同时减少研发成本。

二、应对挑战的架构涅磐

面对这些挑战，我们的应用系统架构应该如何涅磐？主要分如下三大方面系统详解:

存储的涅磐，这一点对于整个系统的吞吐量和并发量的提升起到最关键的作用，需要结合数据存储模型和具体应用的场景。

计算的涅磐，可以从横向和纵向考虑：横向主要是增加并发度，首先想到的是分布式。纵向拆分就是要求我们找到计算的结合点从而进行分层，针对不同的层次选择不同的计算地点。然后再将各层次计算完后的结果相结合，尽可能最大化系统整体的处理能力。

业务层架构的涅磐，要求系统的良好的模块化设计，清楚的定义模块的边界，模块自升级和可配置化。

三、应用系统的整体架构

认识到需要应对的挑战，我们应该如何设计我们的系统呢，下面将全面的介绍下我们的应用系统整体架构。

下图就是我们应用系统整体架构以及系统层次的模块构成。

数据源部分， Hermes是携程框架部门提供的消息队列，基于Kafka和Mysql做为底层实现的封装，应用于系统间实时数据传输交互通道。Hive和 HDFS是携程海量数据的主要存储，两者来自Hadoop 生态体系。Hadoop 这块大家已经很熟悉， 如果不熟悉的同学只要知道Hadoop 主要用于大数据量存储和并行计算批处理工作。

Hive 是基于Hadoop平台的数据仓库，沿用了关系型数据库的很多概念。比如说数据库和表，还有一套近似于SQL的查询接口的支持，在Hive里 叫做HQL，但是其底层的实现细节和关系型数据库完全不一样，Hive底层所有的计算都是基于MR来完成，我们的数据工程师90%都数据处理工作都基于它来完成。

离线部分，包含的模块有MR, Hive , Mahout, SparkQL/MLLib。Hive 上面已经介绍过，Mahout 简单理解提供基于Hadoop平台进行数据挖掘的一些机器学习的算法包。Spark类似hadoop也是提供大数据并行批量处理平台，但是它是基于内存的。SparkQL 和Spark MLLib是基于Spark平台的SQL查询引擎和数据挖掘相关算法框架。我们主要用Mahout和Spark MLLib 进行数据挖掘工作。

调度系统zeus，是淘宝开源大数据平台调度系统，于2015年引进到携程，之后我们进行了重构和功能升级，做为携程大数据平台的作业调度平台。

近线部分，是基于Muise来实现我们的近实时的计算场景，Muise是也是携程OPS提供的实时计算流处理平台，内部是基于Storm实现与HERMES消息队列搭配起来使用。例如，我们使用MUSIE通过消费来自消息队列里的用户实时行为，订单记录，结合画像等一起基础数据，经一系列复杂的规则和算法，实时的识别出用户的行程意图。

后台/线上应用部分，Mysql用于支撑后台系统的数据库。ElasticSearch 是基于Lucene实现的分布式搜索引擎，用于索引用户画像的数据，支持离线精准营销的用户筛选，同时支持线上应用推荐系统的选品功能 。Hbase 基于Hadoop的Hdfs 上的列存储Nosql数据库，用于后台报表可视化系统和线上服务的数据存储。

这里说明一下, 在线和后台应用使用的ElasticSearch和Hbase集群是分开的，互不影响。 Redis 支持在线服务的高速缓存，用于缓存统计分析出来的热点数据。

四，推荐系统案例

介绍完我们应用系统的整体构成， 接下来分享基于这套系统架构实现的一个实例——携程个性化推荐系统。

推荐系统的架构图：

1、存储的涅磐

1）Nosql (Hbase+Redis)

我们之前存储使用的是Mysql, 一般关系型数据库会做为应用系统存储的首选。大家知道Mysql非商业版对分布式支持不够，在存储数据量不高，查询量和计算复杂度不是很大的情况下，可以满足应用系统绝大部分的功能需求。

我们现状是需要安全存储海量的数据，高吞吐，并发能力强，同时随着数据量和请求量的快速增加，能够通过加节点来扩容。另外还需要支持故障转移，自动恢复，无需额外的运维成本。综上几个主要因素，我们进行了大量的调研和测试，最终我们选用Hbase和Redis 两个Nosql数据库来取代以往使用的Mysql,。我们把用户意图以及推荐产品数据以KV的形式存储在Hbase中，我对操作Hbase进行一些优化，其中包括rowkey的设计，预分配，数据压缩等， 同时针对我们的使用场景对Hbase本身配置方面的也进行了调优。目前存储的数据量已经达到TB级别，支持每天千万次请求，同时保证99%在50毫秒内返回 。

Redis这块和多数应用系统使用方式一样，主要用于缓存热点数据，这里就不多说了。

2）搜索引擎 (ElasticSearch)

ES索引各业务线产品特征数据，提供基于用户的意图特征和产品特征复杂的多维检索和排序功能，当前集群由4台大内存物理机器构成，采用全内存索引。对比某一个复杂的查询场景， 之前用Mysql将近需要30次查询，使用ES只需要一次组合查询且在100毫秒内返回 。目前每天千万次搜索，99%以上在300毫秒以内返回。

2、计算的涅磐

1）数据源，我们的数据源分结构化和半结构化数据以及非结构化数据。

结构化数据主要是指携程各产线的产品维表和订单数据，有酒店，景酒，团队游，门票，景点等；还有一些基础数据，比如城市表，车站等，这类数据基本上都是T+1。每天会有流程去各BU的生产表拉取数据。

半结构化数据是指，携程用户的访问行为数据，例如浏览，搜索，预订，反馈等，这边顺便提一下，这些数据这些是由前端采集框架实时采集，然后下发到后端的收集服务，由收集服务在写入到Hermes消息队列，一路会落地到Hadoop上面做长期存储，另一路近线层可以通过订阅Hermes此类数据Topic 进行近实时的计算工作。

我们还用到外部合作渠道的数据，还有一些评论数据，评论属于非结构化的，也是T+1更新。

2）离线计算，主要分三个处理阶段 。

预处理阶段，这块主要为后续数据挖掘做一些数据的准备工作，数据去重，过滤，对缺失信息的补足。举例来说采集下来的用户行为数据，所含有的产品信息很少，我们会使用产品表的数据进行一些补足，确保给后续的数据挖掘使用时候尽量完整的。

数据挖掘阶段，主要运用一些常用的数据挖掘算法进行模型训练和·推荐数据的输出(分类，聚类，回归 ，CF等)。

结果导入阶段，我们通过可配置的数据导入工具将推荐数据，进行一系列转换后，导入到HBASE，Redis以及建立ES索引， Redis存储的是经统计计算出的热点数据 。

3）近线计算（用户意图, 产品缓存）

当用户没有明确的目的性情况下，很难找到满足兴趣的产品，我们不仅需要了解用户的历史兴趣，用户实时行为特征的抽取和理解更加重要，以便快速的推荐出符合用户当前兴趣的产品，这就是用户意图服务需要实现的功能。

一般来说用户特征分成两大类：一种是稳定的特征（用户画像），如用户性别，常住地，主题偏好等特征；另一类是根据用户行为计算获取的特征，如用户对酒店星级的偏好，目的地偏好，跟团游/自由行偏好等。基于前面所述的计算的特点，我们使用近在线计算来获取第二类用户特征，整体框图如下。从图中可以看出它的输入数据源包括两大类：第一类是实时的用户行为，第二类是用户画像，历史交易以及情景等离线模块提供的数据。结合这两类数据，经一些列复杂的近线学习算法和规则引擎，计算得出用户当前实时意图列表存储到Hbase和Redis中。

携程用户意图框架

近线另一个工作是产品数据缓存，携程的业务线很多，而我们的推荐系统会推各个业务线的产品，因此我们需要调用所有业务线的产品服务接口，但随着我们上线的场景的增加，这样无形的增加了对业务方接口的调用压力。而且业务线产品接口服务主要应用于业务的主流程或关键型应用，比较重，且SLA服务等级层次不齐，可能会影响到整个推荐系统的响应时间。

为了解决这两个问题，我们设计了近在线计算来进行业务的产品信息异步缓存策略，具体的流程如下。

我们会将待推荐的产品Id全部通过Kafka异步下发，在Storm中我们会对各业务方的产品首先进行聚合，达到批处理个数或者时间gap时，再调用各业务方的接口，这样减少对业务方接口的压力。通过调用业务方接口更新的产品状态临时缓存起来（根据各业务产品信息更新周期分别设置缓存失效时间），在线计算的时候直接先读取临时缓存数据，缓存不存在的情况下，再击穿到业务的接口服务。

产品异步缓存框架

4）在线计算（2个关键业务层架构模块介绍）

1、业务层架构-数据治理和访问模块，支持的存储介质，目前支持的存储介质有Localcache，Redis，Hbase，Mysql 可以支持横向扩展 。统一配置，对同一份数据，采用统一配置，可以随意存储在任意介质，根据id查询返回统一格式的数据，对查询接口完全透明。

穿透策略和容灾策略，Redis只存储了热数据，当需要查询冷数据则可以自动到下一级存储如Hbase查询，避免缓存资源浪费。当Redis出现故障时或请求数异常上涨，超过整体承受能力，此时服务降级自动生效，并可配置化。

2、业务层架构-推荐策略模块，整个流程是先将用户意图、用户浏览，相关推荐策略生成的产品集合等做为数据输入，接着按照场景规则，业务逻辑重新过滤，聚合、排序。最后验证和拼装业务线产品信息后输出推荐结果；

我们对此流程每一步进行了一些模块化的抽象，将重排序逻辑按步骤抽象解耦，抽象如右图所示的多个组件，开发新接口时仅需要将内部DSL拼装便可以得到满足业务需求的推荐服务；提高了代码的复用率和可读性，减少了超过50%的开发时间；对于充分验证的模块的复用，有效保证了服务的质量。

发布于 2016-08-25 13:46

近几年来，低代码概念越来越火爆，随之而来的低代码产品也越来多，这其中就有很多优秀的产品，目前国内较成熟的低代码平台大体有：简道云、iVX、牛刀、宜搭云、JeecgBoot、ClickPaaS、JEPaaS、华炎、氚云、搭搭云、魔方网表、云表、APICloud、活字格、轻流、明道云。

首先我们先来看一下，什么是低代码？低代码能做什么？能解决什么问题？

“低代码开发”即无需编码或只需少量代码就可以快速生成应用程序。也就是说，企业的应用开发通过“拖拉拽”的方式即可完成。低代码能帮助企业提高开发效率，从而降低成本。

低代码产品

JeecgBoot：★★★★★

JeecgBoot是一款基于BPM的低代码产品，支持微服务。功能全面，可一键生成前后端代码；简单功能也可完全在线完成。既能快速提高效率，节省研发成本，同时又不失灵活性。

• 功能：组件完备，对象封装完整；移动端支持一份代码，多终端适配，总得来说功能非常强大。

• 效率：产品交互设计合理，开发效率高，前端后台（前端Vue后台java）编译出程序的运行效率很高。  

宜搭云、JePaaS：★★★

宜搭云是阿里云的产物；JePaaS是一款开源的CRM工具，但是费用不低；这两款产品都需要使用者使用代码才能进行开发

• 功能：由于接入代码，功能扩展性强

• 缺陷：功能相对单一 

牛刀：★★

是一款很庞大的低代码产品，通过流程图去实现一些代码逻辑。但是在大多数情况下，特别是后台部分，很多场景还是需要以写代码的方式去实现，以至于该产品只适合程序员使用。在平台上没有发现制作出来的比较复杂的应用。

• 功能：功能丰富，但是对象封装以及对象分层还有待改善；支持微信小程序WebView、原生、WebApp，不支持游戏。

• 效率：同样功能的实现需要比iVX多很多倍的点击，窗口切换太多，阻碍连续操作；可能和使用WeX5框架有关，牛刀生成的前端代码质量较差，后台逻辑执行效率比较低，但是由于没看到非常复杂的应用，所以这里也不作过多评价。

• 缺陷：作为一款低代码产品，不可否认的减少了使用者的编码工作量，但无论是产品体验，还是功能上（特别是逻辑实现），还存在不少问题。

0代码产品

氚云、明道云：★★★★

这两款产品做得都挺不错的。氚云是阿里系投的（直接接入钉钉）；明道云是梅花网的，也是很不错的产品。

• 功能：相对比较全面，设计上也比较简单。

搭搭云、简道云：★★★

操作上比氚云和明道云还要简单一些，但是功能稍微少一些，各有优劣

• 缺陷：功能相对单一 

iVX：★★★★★

iVX基于代码生成器和BPM的低代码快速开发平台，是一款比较完备的0代码产品，测试以后发现可以不用任何代码完成所有的开发。

• 功能：支持各种小程序、原生、WebApp、游戏开发，总得来说功能强大。

• 效率：前端后台（前端React后台Go）编译出程序的运行效率很高。

• 缺陷：教学还有待完善，感觉内容较少，初学者一开始上手时可能会有点麻烦。

这几天研究了十几款低代码工具：

iVX 活字格 无远 牛刀 APICloud 氚云 宜搭云 明道 Power Apps 天翎 云表 workfine fineReport 魔方网表 炎黄盈动|AWSPaaS 红圈

各低代码平台

如何分析这些不同类型的产品呢？我总结了几个点，希望对大家有帮助：

• 看这个产品到底能做什么？

• 能做成什么样子？

• 特别是支持的应用场景有哪些？

• 支持系统有哪些？

A 看看网站或自身有没有什么页面是通过自身的平台开发的？如果自己平台都没有使用又怎么放心给用户使用呢？例如，iVX平台全系产品都是通过iVX自身迭代开发的、牛刀网站的大部分都是用自己的平台开发等等

B 看看应用是不是都长一个样？对于很多平台来说，偏模板属性，例如BI、报表等，看来看去就只能做成那个样子，至少说明应用的局限性或至少是前端能力比较弱。

C 调一个比较复杂的后台逻辑来看看，能不能通过非代码的方式来实现？或者看看，如果不写代码，最难能做成什么样？如果这部分没有验证过，后面对于具体项目开发，肯定是一个大坑。特别是低代码平台，由于可以引入代码来开发，好像成为了万能的工具，但其实这是由于代码本身就是万能的，而非平台之功。如果好的低代码平台，代码几乎是可以不用的（例如0代码），或者引入代码只是很少的辅助作用，因为平台能力本身很强。但是，如果平台是辅助，而代码开发是主体，那就本末倒置了，低代码平台就显得鸡肋。

• 看教程、看文档、看Demo、看模板，看学习资源是否完善？

A 看数量和规范程度，有些刚刚开始做的平台，这方面内容会非常少，导致无法自学；或者至少是在学习资源上没有下功夫。

B 看时间，时间越近越好，有些平台是已经做了很久，这本来是好事儿，说明积累时间长（因为低代码开发平台本来就是很有难度的事儿，很难短时间内做好）。但是，当我学习牛刀的时候，居然看到了2014年左右的教学视频，这个就让我比较震撼了，说明平台太长时间没有更新迭代了。课程方面，活字格还是做的不错的，课程很全面，除了官方发布的课程，还有用户的分享课程，课程内容更接近用户的需求。

• 看架构（整体架构、前端架构、后台架构）、看产品、看收费

A 看架构，首先看整体架构是B/S还是C/S，建议大家还是重点关注B/S架构的，毕竟C/S大家懂的，不光难看，而且确实这种产品早晚要被淘汰的，而且也不符合云计算的发展方向；前端架构最好是React的，当然VUE也还可以（对复杂单页应用React性能会更好一些）；后台最好不要是PHP的，或是绑定微软系的产品，例如绑定Azure、Excel、SQLServer、Access...这样系统灵活性就被框死了。

B 看产品，主要看一下产品设计、交互UI、弹框数量...等等产品属性的东西，好的产品总是提供一个最短路径给你，让你使用成本变得很低；如果产品设计不好，有可能做一个同样的东西，你要增加好几倍的操作，操作越多学习时间更长，而且犯错机会也会大好多倍。

C 看费用，这个大家都会看，这个就看大家的消费能力了，没啥好说的。就一点，通过看收费模式，基本可以确定这个产品是否是面向你们群体进行服务的，如果不是就不要尝试了。

接下来，重点来了，我把上面方法论在十几款产品上做了分析，同时还将所有产品，按用户类型分为两类：

适合开发人员使用

适合业务人员使用

一类是“适合开发人员用的”，这里的开发人员是说，学习和操作这个产品可能是一种单独的岗位分工——“开发”，甚至可以形成一种专门的职业（例如：产品、测试和设计师可以学一下，了解一下这个平台，但是兼职做这个平台开发我个人觉得不太合适）。但是，这个“开发”，并不一定要写代码，例如iVX系统，已经是一套完备的0代码开发体系，没有必要再写代码了，但是做的事情仍然是“开发”；活字格、无远等在管理系统的开发方面十分的便捷出色，同样做到了低代码可视化开发。

另一类是“适合业务人员用的”，这个就很好理解的，就是这种平台非常简单，学习一下也很快，业务人员可以直接操作，当然灵活性会稍微小一点儿，场景也会窄一些。

建议大家更具自身的场景需求去平衡这些各种因素，同时考虑到系统的可维护可扩展，“鱼和熊掌兼得”。