标签：portal 频道 需要 控制 导致 RKE 版本 应用服务器 前端
对于京东网站部门来说，CMS核心目的是用来快速开发和上线各种页面，诸如各种垂直频道页，访问www.jd.com将看到如下页面，如点击“服装城”、“家用电器”等都会跳转到一个垂直频道页；这些页面中有许多页面风格是类似的，因此很适合使用CMS进行快速搭建。
CMS最核心的目的是就是进行数据和模板的统一管理、页面的统一发布,从而减少之前的很多重复工作。
京东CMS具有以下特点：
（1）搭建快速，统一发布，统一架构
（2）前后端分离。后端不再负责页面渲染，只提供高性能、可复用的API
（3）移动端页面支持
（4）数据分析、智能投放的特点。
从基本功能及架构来看，可以分为三个阶段：（1）CMS 1.0——虚拟分类系统（2）CMS 2.0——CMS系统（3）CMS 3.0——CMS-portal系统
CMS 1.0——虚拟分类系统
虚拟分类系统是一个独立的促销商品、促销文字维护系统，与具体前端业务架构脱离，哪条线接入虚拟分类，需要根据自己的业务逻辑单独开发、维护、部署自己的架构。虚拟分类系统只是一个基础数据维护平台，无法实现信息的共享、复用和集约化管理。这就会存在各种各样的频道页系统，导致管理混乱，性能上各有差异，出现过很多次事故。而且各系统需要独立配置，导致工作量大，占用资源多，无法快速响应业务需求。
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周，大大提高了业务需求的响应速度；它看起来更独立，更像一个整体，在容灾、规避风险方面做了严谨的优化；同时让采销在维护数据时，更方便、更简单。后续由于个性化的需求越来越多，大量的频道业务需要开发人员一个一个套模板来实现，大大加大了开发人员的工作强度，之前的模板复用方式已经无法满足业务的需求，同时太简单的数据模块，需要手工来绑定数据类型也增加了开发成本，这时候需要必须做出改变。
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负责请求的路由和服务的降级。
no.12京东上千页面搭建基石——CMS前后端分离演讲史读后感
标签：portal 频道 需要 控制 导致 RKE 版本 应用服务器 前端
原文地址：https://www.cnblogs.com/CHAHA123/p/11054822.html
