近两年来一直在跟运营业务打交道，做尽各种专题各种活动，不夸张的说，真的是做到吐。吐定思吐，如何摆脱这种重复的开发工作，节省更多的时间去实现我们改变世界的梦想？请看目录：
业务背景
发现痛点
解决方案
系统设计
快速迭代
未来规划
1
业务背景
产品上线前靠研发，产品上线后靠运营，运营是干什么的？是为了拉新--拉取新用户，留存--留住现有用户，促活--促使老用户更活跃，从而让产品实现营收，那么一个很重要的运营手段就是做各种各样的打折优惠活动，这些活动的一个很重要的线上载体就是专题活动页面。做专题总要有点噱头，于是便有了“每逢佳节做专题”；后来节日不够用了，制造节日也得做。
2
发现痛点
翻开项目排期表，专题开发这边天天过节：5.19，5.20，5.21... 一个专题活动从设计到开发到测试上线怎么也得两三天的时间，光是专题活动的需求就把开发资源占满了，我们还怎么去实现改变世界的梦想~ 如果你无法改变，那么只能去适应，不，我们要改变，改变他们的世界。
1
整理痛点
通过对专题项目的不断反思总结，痛点主要分为三块： 产品层面：专题活动的需求频繁多样，每周3~5个活动，每个活动高度定制； 运营层面：没有趁手的工具，活动产品数据更新、页面调整都要找开发； 开发层面：每次重新开发，效率低，而且代码维护起来也很麻烦；
2
分析问题
针对以上总结的问题，我们该如何应对？要投入更多的开发资源吗？如何让运营自己维护页面？如何积累每次开发的成果？如何降低维护成本？ 通过对问题的梳理和分析，我们得出如下结论：让运营和产品使用平台去制作专题活动，当然平台要足够简单易用，满足各种个性化需求，开发不断在平台上积累，不断完善功能，那么我们要解决的问题就很明确了：一个强大的专题平台。
可是如何去设计这样一个平台呢？
3
解决方案
通过我们之前对问题的梳理和分析，以及与产品、运营小伙伴的讨论，最终制定出如下的解决方案，下面跟大家讲一下具体的思考过程。
1
页面组件化
首先，我们找到所有专题页面的共同点：每个专题页面都是通过一个个的版块拼装起来的，有头图、导航、产品列表、广告位等等，这些版块在开发层面可以抽象为组件；这样，每个页面开发下来，就可以积累下许多组件，随着组件越来越丰富，最终开发页面就变成拼装组件，就如搭积木。
2
可配置组件
那么，我们如何满足页面高度个性化的需求呢？ 我们可以为每个组件添加各种可配置的属性，用户可以通过调整样式属性来决定组件展示成什么样子，通过调整数据属性决定组件展示哪些内容。 这样，通过为组件配置不同的属性就可以实现页面个性化定制。
3
建立组件库
为了让运营和产品小伙伴可以自己搭建页面，我们需要把组件分门别类存入组件库，并且提供可视化的操作界面。 当然，为了能更加简单快捷的搭建出页面，我们需要将组件进一步封装为业务组件，比如：导航组件，列表组件，吸顶组件，吸底组件，轮播组件，视频组件等等~ 我们可以想到：随着开发不断的丰富组件库，运营和产品可制作的活动页面也会越来越丰富~
4
可视化操作
另外，落实到实际的操作界面，我们使用所见即所得的操作方式，可以一边操作一边预览， 界面主要分为三块区域：工具栏，编辑区域，属性面板，
想法都是美好的， 那么如何落地到技术实现呢？去实现我们的梦想吧~
4
系统设计
系统设计主要做了这么几个考虑：
模块划分：把复杂的问题拆分为若干简单的问题去各个击破；
代码组织：如何组织代码更易于阅读，更利于后期维护，扩展性如何，是否能满足需求的不断迭代；
性能：随着功能逐渐增多，页面交互越来越复杂，用户主键增多，访问量越来越大，系统的性能是不是依然良好；
稳定：如何保证系统不间断的提供稳定服务，如何容错，如何监控服务的稳定运行，如何监控页面的稳定运行；
安全：内部系统对安全的要求略微低一些，但是用户侧的访问接口、页面是不是存在安全隐患。
1
前端整体架构
前端代码组织方式是这样的，先按照职责分层，比如负责页面渲染和交互的归到视图层，然后再按照具体的功能划分开，比如负责工具栏的、负责组件属性面板的；如何组织和划分更好，各有优缺点，这里就扯到另一个主题了，就不展开了。 下面看一下前端的具体分层：
视图层：负责页面各个模块的渲染和交互逻辑；
命令层：把用户的每一个封装成命令，把命令保存到操作历史记录，主要为了实现撤销和重做功能；
控制层：封装了下层的调用，对上层提供统一的API，接口隔离；
组件层：这里是一个单独的模块，封装了组件管理，其中包含组件工厂，组件注册中心，组件加载器等；
服务层：主要负责与服务器做数据交互；
模型层：当前页面的组件状态，具体的专题页面的数据缓存。
这里简单的看一下层级划分，下面重点介绍一下最核心的部分，组件设计，整个系统都是以组件为中心的。
2
组间设计--文件结构
先来看一下组件的物理结构，也就是文件结构，系统的加载组件的时候会默认找这些文件，所以这些文件都是必须要有的，其他的文件也可以随便引入或依赖。这也是我们开发一个组件需要遵守的文件结构规范。
3
组间设计--生命周期
接下里是组件的逻辑结构，为了更简单的开发组件，我们给每个组件添加了生命周期方法，就像 react 组件一样；开发组件时，只需要在对应的方法中添加处理逻辑即可；
4
组件属性编辑
组件的属性改如何去编辑呢？开发时该如何更简单为组件添加可编辑的数据？ 我们还记得组件物理结构中包含两个文件：config.js 和 propersForm.js。
在config.js中包含了组件的属性，这些属性我们可以理解为组件的状态；
然后，在propersForm.js中定义了组件的属性面板该如何去渲染：
对，这是一个模板文件，有些不同的是，它编辑后得到的是一个 JSON 字符串。
然后整个属性面板的渲染过程是这样的：
config.js 和 propersForm.js 文件会被编译生成表单配置文件；
表单生成器会根据配置文件去寻找每一个属性对应的 form type，就像我们平常使用的文本框 <input type="test">，但是这里为了简化开发工作，我们扩充了大量的 type ，比如type=colorpicker就是一个颜色选择器，type=media-upload就是一个媒体上传器，type=excel-import就是 excel上传并导入数据的表单项；
表单生成器最终会生成 HTML 代码，交给视图层的属性面板去呈现，我们就看到组件的属性面板了。
5
页面组装过程
组件的设计都了解了，那么接下来看看组件是怎么被拼装成页面的：
展示端或编辑端的专题页面需求组装起来呈现，把专题的数据传递给组装器；
组装器会解析数据，并跟组件工厂要对应的组件实例；
组件工厂到组件库中查询组件；
这时，如果组件库中有预加载的组件则直接返给组件工厂；
如果组件库中没有，则会向服务端请求组件，组件库拿到服务端组件后，缓存到本地并返回给组件工厂；
那么页面中的数据是如何加载的呢？ 每个组件在渲染完成后会去请求数据源，数据源根据请求的业务类型返回对应的数据给组件，这块稍后我们会细讲，继续往下看。
6
组件动态打包
这里是一个性能优化点，为了能够更快的把专题页面展现给用户，我们需要让页面尽可能少的加载资源； 可是我们有这么多的组件，而且还会越来越多，而一个页面用到的组件却没有几个，这里就得按需加载了。 具体怎么个按需加载呢？请看下图：
当用户点击发布专题时，服务端收到请求后查询当前页面所用到的组件；
服务端把所需组件进行打包压缩，生成静态资源及其版本号，替换HTML文件中的静态资源版本号；
同时会把静态资源上传到 Swift 存储服务，会自动同步到 CDN；
用户访问页面时，浏览器就会拉取新的代码，页面就生效了；
当我们修改组件代码时，需要把组件代码同步到对应的专题中，通过管理后台，可以指定某个专题重新发布。
7
后端服务架构
服务端主要包括：搭建 Node.js 服务集群，使用我们自主研发的 node-annotation框架来组织后端代码，对接公共服务；
为了确保用户侧服务能够稳定的运行，同时也是为了应对很多大活动的高并发访问，我们在Nginx中配置了负载均衡，让请求分发到多台机器去处理；
为了能够让服务端更快速的响应，缓存是比不可少的，这里使用公共的Redis服务来做缓存；
为了确保每台机器中的Node进程稳定运行，我们使用了 PM2 来做Node进程管理；
图片、视频、音频等静态资源都上传到公共的Swift服务；
专题的逻辑数据存储使用公共的 Mysql 服务，MySQL-pxc 是一个公共搭建的高可用的 Mysql 服务；
当然，监控和报警也是必不可少的，可以帮助我们实时监控各个环节的指标，一旦有异常及时通过短信或电话通知到开发同学；
最后，对于系统的运行日志，使用Log4js来管理。
5
快速迭代
当初步可用的版本上线后，根据第一批用户的反馈的，需要快速的把迫切需求的功能迭代上去，与用户反馈形成一个闭环； 以下是版本迭代过程中几个重要的功能：
1
多终端适配
专题页面需要在PC、touch、APP三端展示，不同的终端中看到的结果应该是不一样的，而且后续的产品详情下单也需要对接到不同的终端流程中， 这就要求我们的页面可以自动适配不同终端。
那我们是如何实现的呢？ 这里是在组件层面做的，组件分两类：PC端组件和Mobile端组件，根据不同的端去渲染不同的组件。
那如果说PC端页面和Mobile端页面完全不一样，界面结构，用的组件都不一样，怎么实现自动适配呢？ 专题活动也支持两种不同终端的页面分别去搭建，也就是可以关掉组件的自动适配功能，手动去搭建不同终端的页面；这时也是一个访问地址，在不同终端呈现对应的页面效果。
2
组件与业务数据
上面有提到组件中如何展示业务数据的，或者说业务数据如何绑定到组件上。
首先我们会在 form type 中扩展一种叫 data-source 的类型，这个表单项在用户点击时会弹出一个录入数据的界面，在这个界面中用户可以选择录入各种业务线的数据；
然后提供了多种录入方式，可以直接筛选出一批产品，把产品的ID录入进去，这种方式可以满足运营招商的需求；招商的数据量大时，也可以先把数据整理到Excel中，然后再直接导入到数据源；
业务线的接口非常多，总有我们覆盖不到的情况，所以我们提供了一种自定义接口的数据获取方式，用户可以直接输入一个后端数据接口，我们会去读取接口中的数据并展示到页面中，用户可以选择对应的字段来作为列表字段，然后列表中的每一条记录会被解析出来，用户可以通过鼠标拖动的方式把字段拖动到产品卡片的对应展示区域中，这样就建立了字段的映射关系，接口数据就可以被正确展示出来了。
3
另存为活动模板
为了最大化的提升新建专题活动的效率，用户可以把一些常用的专题整个保存为模板，下次再有类似版式的专题需求时，只需要通过选择模板的方式创建专题，然后改改数据、换换图片，在几分钟内就可以上线一个专题。
4
H5整页动画轮播
为了满足推广需求，专题系统中还支持了H5动画轮播页面的制作，就是那种整屏翻页类似PPT的那种页面，有很多的动画元素在里面；目前市面有很多类似的平台，但不是收费就是带广告，使用专题系统制作就不会有这种烦恼了。
5
后评估
在有专题系统之前，做一个专题页面需要2~3天的时间来走完整个需求-设计-开发-测试-上线的流程，有了专题系统之后一天可以上线10~20个专题，这完全取决于产品和运营的需求量。
别忘记了我们的梦想~
6
未来规划
1
更好的制作体验
PSD生成专题：为了解决产品和运营同学切图的烦恼，我们正在支持直接导入PSD文件来生成专题的功能，又可以极大的节省工作量了。
AI辅助制作：为了解决产品和运营同学对于专题的配色、版式等设计方面的烦恼，我们准备通过AI来辅助他们，在制作前给出建议，并对制作后的页面提出修改建议，帮助他们设计出更好的页面。
2
更好的开发体验
组件热发布：我们计划把专题系统做成一个开放的平台，让所有人都可以提交组件，组件审核后即可在线上使用，不需要走测试发布流程。
在线开发组件：为了方便开发，我们计划提供一个在线的开发平台，提供组件线上调试环境，不需要本地搭建环境也可以开发组件。
3
更好的用户体验
React Native：为了让用户有更好的体验，我们计划在 APP 中使用 RN 来展示页面。
微信小程序：在微信中打开专题活动，会跳到小程序中展示页面。
联系客服
