《京东上千页面搭建基石——CMS前后端分离演进史》阅读笔记
一、背景
CMS即内容管理系统，目的是用于快速进行网站建设或者网页开发。
对于京东网站部门来说，CMS核心目的是用来快速开发和上线各种页面，诸如各种垂直频道页。
二、CMS核心目的
进行数据和模板的统一管理、页面的统一发布,从而减少之前的很多重复工作。
三、CMS特点
1、搭建快速，统一发布，统一架构
2、前后端分离。后端不再负责页面渲染，只提供高性能、可复用的API
3、移动端页面支持
4、数据分析、智能投放的特点。
四、从基本功能及架构来看，可以分为三个阶段：
1、CMS 1.0——虚拟分类系统
虚拟分类系统是一个独立的促销商品、促销文字维护系统，与具体前端业务架构脱离，哪条线接入虚拟分类，需要根据自己的业务逻辑单独开发、维护、部署自己的架构。虚拟分类系统只是一个基础数据维护平台，无法实现信息的共享、复用和集约化管理。
这就会存在各种各样的频道页系统，导致管理混乱，性能上各有差异，出现过很多次事故。
而且各系统需要独立配置，导致工作量大，占用资源多，无法快速响应业务需求。
2、CMS 2.0——CMS系统
Cms2.0总结了1.0时的不足，从节省资源、控制成本的角度考虑，把导购类的个体页面业务进行了统一，模板能复用的复用，以前虚拟分类系统的频道也需要迁移到新的系统。
改动如下：
（1）、CMS 2.0数据结构适合虚拟分类体系，方便新老数据兼容；
（2）、升级架构，统一配置、发布流程；去memcache为redis，做大量性能压测来调优php-fpm配置，单机TPS能达到3000+； 配置定时任务，保证redis数据实时性；
（3）、单点发布，一键预览增强采销维护数据的机动性；
（4）、单机闭环，单机闭环服务设计是CMS整体架构的核心部分，需要展示的内容在本机获取、封装、校验；
（5）、模块化、动态数据类型初期版本
对比1.0，新的CMS可以让频道页的开发周期降低2~4周，大大提高了业务需求的响应速度；它看起来更独立，更像一个整体，在容灾、规避风险方面做了严谨的优化；同时让采销在维护数据时，更方便、更简单。
后续由于个性化的需求越来越多，大量的频道业务需要开发人员一个一个套模板来实现，大大加大了开发人员的工作强度，之前的模板复用方式已经无法满足业务的需求，同时太简单的数据模块，需要手工来绑定数据类型也增加了开发成本，这时候需要必须做出改变。
3、CMS 3.0——CMS-portal系统
CMS 2.0后也存在很多痛点，因此在CMS3.0上解决这些问题：
（1）、本质问题就是要快：快速支持、响应业务越来越多的垂直化页面改版；
（2）、前后端分离，页面渲染让前端实现，解放后端让后端做高大上的事情；
（3）、减轻运营人员的工作量，系统简单好用，提高导购类商品的转化率；
（4）、其他系统的支撑，实现CMS的集约化管理；
（5）、 兼容手机端；
（6）、站点管理、统一架构、容灾、高性能、水平扩容；
五、统一架构主要分为以下几个部分：
1、CMS系统：统一管理CMS相关数据，并进行页面的生成和发布；
2、数据Worker管理中心：调用第三方服务进行数据校验（如库存不足补货），并调用CMS系统进行页面生成和发布，发布到单点服务器上；
3、单点服务器：相关页面的单机闭环实现，即CMS发布的页面会存储在这些单点服务器上；每个机房会部署一台；
4、页面定时更新Worker：定期同步单点服务器内容到静态应用服务器集群，并保存历史版本，当出现问题时可以切换回上一个版本；
5、静态应用服务器集群：静态托底实现，会存储相关的静态页面文件，当单点服务器挂了时，降级到该集群；
6、异步加载的个性化服务：有些数据不能存储到静态页，如价格/库存/推荐等数据，此时通过异步加载这些数据，实现个性化服务；
7、接入层Nginx：接入层Nginx负责请求的路由和服务的降级。
原文链接：
