【案例】全国知名网上书城——基于企业中台构建智慧悦读体验

Original 端点科技数据猿

“本项目案例由端点科技投递并参与由数据猿&上海大数据联盟联合推出的“行业盘点季之数智化转型升级”大型主题策划活动之《2021中国企业数智化转型升级创新服务企业》榜单/奖项的评选。

数据智能产业创新服务媒体

——聚焦数智 · 改变商业

某全国知名网上书城通过文化+技术+渠道，创新引领传统书店转型发展，着力推进全行业信息互联互通，构建行业数字中台，更好地满足读者需求和行业健康发展提供服务和平台保障。

随着网上平台的不断发展与壮大，需要在既有项目建设成果上，继续拓展多业务域的合作发展模式，完善相关能力优化建设，支撑平台创新业务模式的发展，更好的实现线上线下融合，为各类用户提供便捷、高效的服务体验。

本次项目将继续丰富平台功能，打通平台业务合作壁垒，进一步夯实商城发展基础，同时为了保证网上书城项目各模块云平台建设的顺利实施，保证运营活动的正常推广，需要搭建更佳完善的系统架构，从稳定性、安全性、扩展性等多个维度构建技术保障体系。

●实施时间

开始时间：2021年1月

截止时间：至今

应用场景

1、线上与线下融合

集合全国实体门店、仓储配送与传统出版物“进销存退”优势资源，推进线下实体书店体验与网上书城营销的无缝对接，推动实体门店多元化、数字化、智能化的转型升级。

2、产业与市场融合

不断创新主题出版物发行营销方式，通过全品种服务及线上线下同价，推进出版物生产、营销等市场主体的利益共同体建设。网上书城激活全国书店系统会员数据，将出版社、书店、图书馆、读者链接，为读者提供个性化、专业化、多元化的阅读服务。

3、文化与技术融合

逐步开发出版物综合销售、精准馆配、大数据应用、物流、文创产品定制、供应链集采服务等多个业务板块，推进产业转型创新与协同发展。发挥门店优势，建设智能物流配送系统，实现产业资源的高效盘活。

4、多维度技术保障体系

针对在线商城，以及门店、图书馆、出版社、电子书、用户内容、数据分析、整合营销等模块进行功能新增和开发，以有效提升网上书城产品功能及运营效率，更好的为C端用户和出版社、门店、图书馆等B端合作伙伴用户服务。经开发小组、运维小组讨论，从稳定性、安全性、扩展性等多个维度构建技术保障体系。

面临挑战

1、业务需求的压力：业务应用和用户数量的增加，对于系统性能的压力会越来越大。

2、资源规模的压力：未来服务器资源数量增加，对于服务器资源的管控压力会越来越大。

3、稳定性的压力：未来业务系统的需求越来越高，机器故障，系统故障，业务故障，数据故障等发生机率会增加。

4、海量数据的压力：业务增长和用户增长带来数据的指数增长，在外来海量数据的处理和运营将会给系统带来巨大的压力。

数据支持

1、整体项目在实施落地过程中，Erda需要为其提供稳定健康的技术保障，其中对于基础资源需要托管运维的机器数量80余台，中间件多达十几个。

2、需要面对200多个微服务在四个完整的环境（开发、测试、预发、生产）下保证可持续迭代部署。

3、在特大的营销活动中，达到毫秒级响应速度。

应用技术与实施过程

01

应用技术

1、云资源弹性引擎

做到“以应用为中心”，有两点至关重要：

• 1）开发者能够通过声明的方式，告诉平台应用运行的所有基础设施，从而完全对底层（例如 Kubernetes）不感知。

• 2）同样通过声明的方式，开发者告诉平台应用所需的所有通用能力，但不需要知道提供通用能力的搭建过程。

为此，我们在架构上实现了一个抽象层 “云资源弹性引擎”。

2、向下管理基础设施

• 1）多云调度能力

公有云可以获得更多弹性伸缩的能力，私有云可以用于存放企业数据。这种场景下企业可以结合经济效益或者安全因素进行取长补短。

支持两个及以上公有云服务提供商。这类场景下一般是出于战略布局不希望被单一云服务厂商绑定。或者是因为地理位置的原因需要选择当地的其他的服务商。特别的，基于 Terraform 编排可以自动化实现云资源的快速购买和安装。

部署到不同的集群隔离开发/测试/预发/生产环境隔离满足业务研发过程及安全生产的要求。同时也支持将业务与数据的环境分离到不同的集群中实现业务和数据业务分离。

• 2）云原生能力

基于容器引擎 Kubernetes 实现资源统一池化管理，实现不同类型资源的统一调度和运维管理。应用开发者只需关注业务本身，通过代码声明的方式按需使用资源即可，而无需感知底层资源，也不需要了解容器和 Kubernetes Deployment、Statefulset、Service、 Ingress、Pod 等概念。容器具有轻量易部署的特点，可以适配业务需要完成服务能力的弹性伸缩。

3、向上提供通用能力

• 1）抽象的工作负载。

基于 Kubernetes 抽象出两类工作负载：“长时运行服务”（Service）和“短时运行任务”（Job）。进一步，通过 Orchestrator 编排有状态（Stateful）和无状态（Stateless）两种服务；通过 Pipeline 调度任务流（WorkFlow）、批计算（Batch）和流计算（Streaming）。

• 2）基础的核心服务

基础的服务包括分布式日志、立体式监控、容器镜像仓库、开发包管理等。

• 3）服务插件的能力

通过服务插件能够提供屏蔽中间件部署，提供统一的管理。这里的插件包括开源的中间件、云厂商的 SaaS 服务和企业内部已经建设的内部其他系统。

4、DevOps 研发效能

基于云资源弹性引擎，在建设业务系统时能够不受异构基础设施的影响，能够做到以应用为中心。进一步，为了提高项目研发效能，我们实现一站式的应用编排、CI/CD和持续交付，同时实现了一站式的项目人员大协同。

5、应用编排

通过让开发者声明的方式告诉平台微服务运行的整个环境，而由平台负责将这个声明编排成环境的搭建过程。我们通过一个 yaml 文件的方式让用户进行声明，分为两部分：

一部分是微服务的声明，包括有哪些微服务，以及各个微服务所需的资源、副本个数、端口、环境变量，甚至是对外网关的域名、网关的转发设置。

另一部分是扩展服务的设置，我们称之为 add-on，而中间件就是其中的一类 add-on，可以看到开发者只需要声明应用用到了哪些 addon，比如 mysql，指明 mysql 的规格、版本即可，平台会自动为应用创建这个 mysql，并将 mysql 的配置通过环境变量的方式传递给微服务。并且 addon 是支持扩展的，通过这一开放的方式，可以将所有的三方依赖集成进平台。

Kubernetes 也提供了 yaml 的声明方式，那为什么不让开发者直接用 Kubernetes 的 yaml？这里需要强调一点，那就是“关注点分离”。Kubernetes 本身不是一个面向开发者的平台，而是面向平台的平台。

图中列出了我们平台的 yaml 和 Kubernetes 的对比，Kubernetes yaml 中有太多开发者不需要关心的基础设施方面的细节。

虽然事实上我们平台的 yaml 底层实现也是如此转换成 Kubernetes yaml 去进行部署的，但我们认为开发者应该关心自己需要关心的，而平台应该将用户不需要关心的事物彻底屏蔽。

最后，通过这一文件，开发者在中心平台经过验证的部署过程，几乎不需要修改就能同时适配到客户环境，为一键部署打下了基础。

6、一键部署

最常规的方式就是通过编写脚本来串联编译构建以及部署的过程，来完成CI/CD。最开始我们也是通过 jenkins 拼凑脚本来实现的。但是对开发者而言，他关注的其实是最核心的那条编译命令，而其他准备和善后工作都应该由平台负责完成。按照这个思路，我们通过流水线 yaml 文件编排 CI/CD，屏蔽底层细节。

我们设计了一个极简的配置语法，整体只有 stage / action 两级。stage 就是阶段，它用于控制串行和并行；action 则是实际的执行单位。action 不等于脚本，其被设计成高度封装的功能逻辑，可以被参数化使用。并且 action 是支持扩展的，理论上任何短时任务/作业都能被封装成 action。

其中由平台默认封装的 buildpack action 提供了通用打包能力，开发者几乎不需要配置任何参数，就能自动识别程序语言、版本和框架，执行正确的编译打包过程。平台也默认提供了代码扫描、单元测试等准入相关的 action，也同样开发者几乎不用做任何配置就能使用。

这样开发完成的功能一旦被确认通过，就能源源不断的部署到测试环境，等待测试。测试人员这时会怎么做？一般情况会等到项目提测，才会全力进行测试。当我们前期的流程越来越顺畅，就发现人工测试效率的瓶颈会阻塞最后交付的效率。

7、持续交付

这时就需要通过自动化测试来解决这个困境，其中最主要的是自动化接口测试。

我们设计了场景集-场景-接口三级概念。场景是具体的一个业务场景，比如支付场景，需要登录、访问商品、下单、支付等一系列的接口调用，并且这些接口的出参入参环环相扣，最后通过断言执行判断场景是否执行通过。而场景集，聚集了同一个业务领域下的所有场景，包括正向的，逆向的，比如有判断支付失败的场景，可以故意构造问题的参数，最后断言支付失败。场景集内允许场景之间的串联，比如可能统一个领域的场景都要公用登录场景，而领域和领域之间做到了相互隔离。

另外我们还实践了 API-First 理念，并且通过一系列功能支撑开发者先进行接口设计，再做功能开发或者功能调整。基于这个实践，自动化接口用例中就可以直接与接口设计结构化关联，所有接口的设计都能自动同步到自动化接口用例、并通知到测试人员。

8、项目协同

敏捷和 DevOps 渊源不断。站在项目的角度，我们实现了一套偏向敏捷的事项协同工具，其中有需求、任务、缺陷，也有迭代、里程碑、看板等。我们甚至实现了工作流程调整以及事项字段包括状态的自定义。

基于工具之上，敏捷更多的是一套项目研发协同的机制和一种团队文化建设。我们推崇异步协同的机制，推崇技术框架和管理策略的平衡。

9、微服务观测治理

基于 DevOps、微服务、容器化等云原生的能力，可以快速、持续、可靠和规模化地交付业务系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战，比如：

• 模块之间的调用从进程内的函数调用变为进程间的调用，而网络总是不可靠的。

• 服务的调用路径变长，使得流量的走向变得不可控，故障排查的难度增大。

• 引入 Kubernetes、Docker、Service Mesh 等云原生系统，基础设施层对业务开发团队来说变得更加黑盒。

在传统的监控系统中，我们往往会关注虚拟机的 CPU、内存、网络、应用服务的接口请求量、资源使用率等指标，但在复杂的云原生系统中，仅仅关注单点或者单个维度的指标，并不足以帮助我们掌握系统的整体运行状况。在此背景下，对分布式系统的“可观测性”应运而生。

10、可观测性

可观测性相对于过去监控最大的变化就是系统需要处理的数据从指标为主，扩展到了更广的领域。综合起来，以下三类数据被看作是可观测性的支柱：

• Metrics，是一种聚合数值，存储空间很小，可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。这个时候使用等高线指标等多维数据结构来增强对于细节的表现力。例如统计一个服务的 TBS 的正确率、成功率、流量等，这是常见的针对单个指标或者某一个数据库的。

• Tracing，面向的是请求，可以轻松分析出请求中异常点，但与 logging 有相同的问题就是资源消耗较大。通常也需要通过采样的方式减少数据量。比如一次请求的范围，也就是从浏览器或者手机端发起的任何一次调用，一个流程化的东西，我们需要轨迹去追踪。

• Logging，展现的是应用运行而产生的事件或者程序在执行的过程中间产生的一些日志，可以详细解释系统的运行状态，但是存储和查询需要消耗大量的资源。所以往往使用过滤器减少数据量。

图片来源 Peter Bourgon · Metrics, tracing, and logging

11、可观测架构

为解决可观测性数据的融合存储和分析，我们自研的统一存储和查询引擎，提供了指标、追踪和日志数据的无缝的“可观测性分析诊断”。

• 观测：观察服务自身的运行状态和监控指标。

• 分析：对观察数据进行关联、统计、加工等。

• 诊断：基于观察数据的分析结果，描述出系统异常的直接原因。

12、多采集端的 Agent 技术

数据采集覆盖了从基础设施、业务系统、到端应用的数百种指标和状态。

• 浏览设备 ta.js：在网页或者 App 打开时加载 ta.js，持续收集设备、访问路径、性能明细等数据。

• Java/Nodejs/Golang Agent：在镜像打包时内置，应用运行期持续收集事务、异常、进程指标。

• 日志 filebeat：在云主机部署时安装 filebeat，持续收集 Pod 中容器的日志。

• 系统 telegraf：在云主机部署时安装 telegraf，持续收集内存、CPU、网络、磁盘、负载、容器等指标。

13、以项目应用为中心的数据分析诊断

• 1）以项目应用为中心的拓扑

每个项目都会有一个唯一的 Key 标识，所有的观测数据都会带上这个 Key，同时，对应项目下的应用和服务的信息也会被记录。后继分析以项目视角展示应用架构拓扑。可以从架构拓扑图观测业务运行期的状况，包括访问量、异常、错误等。

• 2）慢/错误事务分析

针对于业务系统的慢请求和错误请求，我们通过请求 ID 集成了 log、trace 和 metric 的关联，让用户可以很容易地定位到请求的异常上下文信息。

• 3）日志分析

对日志数据的处理，支持全文检索和结构化标签检索两种方式，并且实现一键关联日志和调用链路的分析能力。

02

实施过程

1、Erda 技术平台搭建

端点旗下新一代企业级云原生 PaaS 平台Erda，帮助企业快速的构建一个完整的 DevOps 链路，实现从代码构建、持续集成、持续部署直至运维监控，有效的提高企业的 IT 研发、运维、运营效率，降低成本。Erda 基于容器云平台，提供了遵循 GitFlow 规范的代码托管机制；采用 Pipeline 模式实现了代码编译、测试、打包等一系列的构建流程；采用 pipeline.yml、dice.yml标准规范实现基础设施的可编程性，从而遵循基础设施即代码的设计理念，实现企业的复杂 IT 软件、项目以及分布式服务、微服务等的一键编排部署和准确高效的监控运维；同时，作为一个 PaaS 平台，Erda 以 AddOn 方式提供开箱机即用的数据库、中间件以及通用服务的基础能力，助力软件、项目、微服务的研发运维。

网上书城项目的开发、上线及运维，都是基于 Erda 平台展开，所以实施的第一步需要先完成 Erda 平台的部署。

• 1）确定部署架构，完成资源准备

出于安全的角度，给项目规范了合理的部署架构，将 Erda 平台、电商生产、非生产环境，从 IaaS 层就完成隔离，并通过 CEN 完成白名单方式的互通。

再根据部署架构，梳理平台及业务所需资源，完成云资源的采购，包括虚拟机、网络、存储等设备，完成域名的分配及映射，完成了操作系统统一、登录账号管控、时间同步等准备工作。

• 2）平台安装

2.1 获取软件包

2.2 预安装

2.3 准备安装配置文件

2.4 安装 Erda 平台

2.5 完成平台初始化配置

• 创建企业

• 添加集群

• 创建项目及应用，并添加对应的人员，进行合理赋权

2.6 完成电商生产 & 非生产集群搭建

参考 2.4 及以上的步骤，完成电商生产 & 非生产集群的搭建，并导入到 Erda 平台，赋予给电商项目使用。

注意1: 2.3 准备安装配置文件时，需要将 config.yaml 中 is_edge_cluster 设置成 true。

注意2: Erda 项目支持四个环境：开发、测试、预发、生产，需要将生产集群配置到生产环境，非生产集群配置到其他环境，用于集群级别的环境隔离。

2、基于 Erda 完成电商项目开发到上线

完成 Erda 平台的搭建，并准备好相应的项目资源后，即进入电商项目启动阶段。

• 1）项目进入开发阶段

Erda 是企业级云原生PaaS 平台。企业从代码管理，代码检查，单元测试，CI/CD，自动化测试、项目协同等，项目开发测试过程所需用到的功能，都能在 Erda 上完成一站式操作。该电商项目涵盖了大量的微服务及中间件：

• 微服务：交易中心、商品中心、订单中心、库存中心、促销中心、结算中心、移动应用、微信小程序等。

• 中间件：MySQL、Redis、ElasticSearch、OSS、MQ、API 网关、配置中心、注册中心等。

这些微服务及中间件，都通过前面介绍的应用编排文件 erda.yaml 中进行声明，完成一键部署。

• 2）项目进入集成测试阶段

所有的产品模块开发完之后，进入集成测试阶段。

• 3）项目进入预发布阶段

集成测试通过之后，需要进入预发布阶段，准备一个与生产一致的环境，并进行压测，达到客户要求的业务指标。

• 4）进入生产发布阶段

压测通过后，进行生产环境发布。

从开发到上线的过程只是占了整个项目生命周期很小的部分，后面的整个运行期才是最长的，这里就涉及了项目的运维，可以通过 Erda 微服务治理，观测整个项目的状态，及时发现及定位异常问题，能快速解决。

商业改变

1、资源整合快速推进

网上书城正式上线运营以来，目前已与全国20多个省份的实体门店实现业务系统对接，进行线上销售和集中采购业务；与全国数百家出版机构建立了业务合作，上线百万种优秀图书。

2、平台功能不断完善

网上书城APP上线实现PC端、移动端全网联通。APP上线以来，实现纸质图书、数字图书在网上书城的同步销售；推出网上书城与实体书店，线上线下营销一体化运营体系。

3、市场运营成效初显

网上书城开展了各类营销活动，频繁获得媒体报道，得到普遍好评，品牌形象深入人心。同时，还联合各地实体门店参加各类书展，利用双方各自线上线下资源优势，联合宣传推广，整合营销，提升品牌影响力和经济收益。