nice服务端架构重构与演进
程序员文章站
2022-05-13 14:13:42
...
由于一直以来都是做php的, 并且文中涉及的源代码也都是php相关的.
所以就发到php版块了. 如果zuning版主觉得不合适, 请帮忙转移下...
为避免广告嫌疑. 已摘除公司介绍部分.
另外, 分享当时的一些问答, 也没有转过来.
看原文请点下面链接到公众号文章.
现阶段，nice 服务端主要面对以下几方面挑战：
系统设计，面向变化，必须能够很好地支撑“产品探索阶段”需求的多样性。
稳定性，避免稳定性问题对现有用户造成伤害，同时还需要应对业务突发性增长。
协作，麻雀虽小五脏俱全，服务端作为客户端、策略推荐、大数据、QA、运营、产品等各团队的桥梁，如何通过技术或非技术手段解决好各方的桥接。
“推倒重来”：nice 的重构之路
刚加入 nice，我就接到一个极具挑战性的任务，重构服务端整体业务及框架。和很多创业团队一样，我们在成长过程中积累了一系列技术债务。
旧系统是使用 CI 框架编写的，没有模块的划分，没有明确的分层，入口处直接进行各种业务处理，几乎没有复用。
API 的版本管理，是直接目录拷贝，随着业务的发展，已经需要同时维护十多个版本的接口代码，痛苦不堪。
代码中充斥着 if ($isAndroid && $appVersion >= 3) 这样的兼容逻辑。
以至于客户端/服务端联调基本靠喊。我相信初创公司很多朋友都经历过这些问题。
旧系统架构
旧系统架构是一个最典型的一体化的应用架构：后台、 HTML5、接口全部都揉在一起。
面对当时的状况，首先分析要解决的问题，认为下面 3 个问题比较关键。
结构性问题。代码结构混乱，无法复用。
客户端差异管理。接口版本拷贝导致重复代码量巨大，主要针对特定客户端的特殊需求/灰度/小流量等问题。
客户端/服务端 RD 协作问题。
分层和模块化
首先，从大的角度来考虑，可以用简单的两层架构来解决第一个问题。
应用层和服务层在编码层级进行划分：
应用层解决入口的问题，比如交互协议、 鉴权、 Antispam 等通用服务接入以及各端个性化需求。
服务层解决业务逻辑的问题，将服务层按照业务做垂直的模块划分。
通过层次和模块的划分，代码管理变得清晰，逻辑复用性大大提高。同时，业务划分也为后面的业务隔离和分级管理提供了基础支持。
两个基础组件
上述客户端差异管理以及客户端与服务器协作，通过框架的两个基础组件来解决：
ClientAdapter：客户端适配器，用来处理所有客户端差异导致的逻辑问题。
CKCR：CheckAndCorrect，数据的检查和修正，用来控制输入输出协议，解决客户端/服务端 RD 协作的技术层面问题。
ClientAdapter 组件
先来看一个 ClientAdapter 的应用场景。
以上面配置为例，可以实现以下常用的类似规则。
所有客户端为 3.1.0 及以上版本，支持"打招呼"功能。
所有客户端为 3.1.0 以上版本，灰度渠道 abc36032 为 3.1.0 版本，支持"表情"功能。
大家看以上 nice 代码，通过这种方法，逻辑上 nice 应对的是各种 "Feature"，而不是具体的客户端环境。上面例子就是 ClientAdapter 的一种应用场景。
ClientAdapter 的整体结构
ClientAdapter 最基础的部分，是抽象出一个”客户端运行时环境”的概念，用它来描述发起每次请求的客户端的各种信息，比如系统、App 版本、IP、网络制式、 网络运营商、 地理位置等。另外，它提供一种简单的描述规则，用来描述一种受限的客户端环境。
应用层面，它仅对外暴露 checkEnv() 接口，用来检查当前客户端是否满足给定的描述规则。在这个基础设施之上，nice 上层有很多种应用。
比如原本客户端的差异会导致nice面对复杂的客户端适配，通过 NiceFeature，在 Feature 机制下，RD 面对的其实是一个个产品迭代的 Feature。再比如在 NiceUrl 中，nice 中实现了 CDN 的统一调度，通过 ClientAdapter，我们可以灵活控制各个地区使其采用不同的调度策略。
另外，在处理用户分流方面，这套机制所提供的灵活性也能够满足 nice 按照多种维度进行实验用户抽取的需求。
ClientAdapter 开源地址
ClientAdapter 这个组件实现非常简单，只有 200 行。代码已经摘出放在 github 上了，供大家参考，网址为：http://t.cn/RGnqnpj。
补充一点，ClientAdapter 的设计参考了 C 语言中的常用手段。在 autoconf 阶段，将系统的各种环境信息定义为各种各样的 HAVE_XXX 。这样就达到了环境本身的复杂性和实际的业务代码进行解耦的目的。
CKCR 引入
上述问题 3，客户端/服务端 RD 的协作问题，这个问题分两部分。
技术层面：协议层的约束。
流程层面：怎么配合工作。
技术层面上，要解决的问题是怎么让接口协议确保执行。从输入的角度看，我们要不信任客户端，只要协议约定建立就得按规则来，避免客户端被“坏人”控制，对服务造成伤害。从输出的角度看，要将业务层返回的数据确保按照协议约定传输到客户端，避免导致客户端产生不期望的结果，比如常见的类型不 Match 导致 Crash。
一言以蔽之，就是对输入数据的校验和输出数据进行修正。因此，nice 在这里引入了一层叫 CKCR 的组件，全名为 ChecK && CorRect。
CKCR 实现
CKCR 实现了一套很小的描述性语法规则。通过这套语法来描述要对数据进行的校验和修正。校验和修正行为是可以*扩展的，下面是它的一个应用示例。
这个示例中，$data 代表要被处理的数据，$ckcrDesc 就是这个语法规则的描述串。它描述的规则如下。
整体数据是一个 KV 数组（Mapping），只保留 user 和 shows 两个子键的数据。
user 也是一个 KV 数组，它的 id 是 int 类型，name 是 str 类型。
shows 是一个数组，数组中每个元素是一个 KV 数组，过滤掉它的 id 子键，它的 url 子键，应用 imgCdnUrl 的自定义处理（执行 cdn 调度）。
它和 protobuf、Thrift 的 scheme 有相似之处，也有区别。差异主要在于，CKCR 提供的是一种可扩展的数据校验/修正的通用做法。由于这种扩展性，使得它可以对共性数据，在通用层做更多的文章。比如上面例子中的 imgCdnUrl 就是 nice CDN 调度的统一挂接点。
CKCR 内部结构及语法规则
上面是 CKCR 的基础功能。后来在应用中发现，在系统各个场景下，系统核心数据输出的数据结构大部分是一样的。因此，CKCR 描述串的复用性就成为了一个问题。
为了解决这个问题，nice 在 CKCR 编译之前，引入了预处理的机制。可以通过特殊的语法，引用固定的数据结构描述。这个机制引入之后，带来了一个附加的好处，即沉淀系统的核心数据结构。
客户端/服务端协作问题，技术层面 nice 通过这个组件解决。那么，人的协作问题怎么解决?
首先，CKCR 的描述规则是简明的。所以，它可以直接作为接口文档输出。
其次，在接口文档的基础上，nice 服务端和客户端 RD 之间的协作，流程上有一个明确的方案。
定协议：双方 RD 沟通，约定接口协议并提供文档，双方各自进入设计阶段。
假数据：服务端 RD 快速提供 Mock 数据的伪接口，供客户端 RD 基础功能自测使用。
真接口：服务端 RD 提供真实接口，双方联调。
这样分步的开发方式，基本就解决掉了”联调靠喊”的问题。双方的工作基本解耦，并且也基本不影响双方的开发进度。
CKCR 开源地址
CKCR 这个组件的源代码，已经摘出来放在 github 上了，网址为：http://t.cn/RGn57Xk。
第一阶段总结
上面这些就是 nice 应对第一阶段 3 个问题的方案：
分层和模块化：通过两层架构，解决掉结构性问题。
客户端适配器：解决掉客户端差异的问题。
CKCR：通过 CKCR 及协作流程，解决掉客户端/服务端 RD 协作的问题。
这个阶段，主要通过整体的重构，解决掉开发的问题，同时为未来的架构调整铺平路。
当时的做法是”推倒重来”，现在回顾，这种选择就当时的情况来说是正确的。在那个时间前后，我们没重构系统所遗留的问题，在系统变得更加庞大之后，变得更加棘手。
不过，话说回来，“推倒重来”的重构之路，毕竟还是充满了各种风险的，做这样的决定前，一定要做好充分的资源和风险评估。
为稳定性填的那些坑
在完成整体性的重构之后，nice 进入了业务的快速开发。2015 年 3 月还搞了一个月的 SpeciaForce，研发团队几乎所有人都住公司附近，7 * 14 小时以上的工作量。那段时间的冲刺，为我们的产品带来了日活等关键数据的提升，接口 PV 也达到了最高峰的 5 亿/天。
直到 2015 年 8 月，服务的稳定性经受了很大的考验，说实在的，我当时都快崩溃了，最重要的几类问题如下。
1、MySQL 扛不住
nice 的 MySQL 集群最初就是单实例单库，一主四从，机械硬盘。2015 年 4 月，跟很多业务增长很快的团队一样，为了快速解决问题，OP 把所有的 DB 都换成 SSD，收益非常大。
另外，由于考虑单库导致服务无法隔离，主库的写入也成为瓶颈。2015 年 3 月左右，nice 开始着手考虑分库/分表的事情。分库的方案，主要按垂直的业务进行划分。
技术债真是欠不得！！！
分库整个耗费了两位同学差不多半年的时间。接下来又用了大概一个季度的时间，针对系统的核心大表，进行表的拆分。
在 MySQL 这块儿，我们的教训如下。
用硬件解决问题，性价比非常高。
库的业务线划分，表的规模评估，这样的事情，千万马虎不得。提前做可能多几人天；拖后做可能就像我们需要甚至超过 1 人年的时间去擦屁股。
另外一方面，nice 对 Redis 的依赖也是很重的。一部分数据，是典型的 Cache用法。在线业务访问 Cache 没有的时候，会自动 fallback 到 DB，去冲 Cache。另外一部分数据，是准持久化数据。这部分我们在线业务不会 fallback 到 DB。
2、Redis 扛不住
nice 的 Redis 也是单集群。大概 2015 年四五月的时候，随着业务的快速迭代，很多新功能上线，Redis 的压力迅速增大，开始偶尔出现 Redis 故障。那个时候，nice 就开始了 Redis 的服务拆分。因为业务模式比较简单，所以 Redis的拆分速度是比较快的。
但同时，由于故障中丢过数据，我们决定在 Redis 高可用方面做一些自主开发。主要是针对平滑扩容、 故障自动切换等方面。
由于这方面经验并不是很足，导致出了不小的问题。最严重的一次，上线试运行阶段没有发现问题，但切到全量后，多个集群节点接连出现问题。硬扛了两天左右，最后扛不住，只得往回切换。然而，当时又面临机器资源的问题，做不到一次性全量切回，只能逐集群切换，同时搭上几个 RD 去写几乎所有的准持久化数据的恢复脚本。
Redis 这块儿的教训是非常惨痛的，从 2015 年的踩坑经历来看，我们的收获是如下。
压力与容量评估的经验
压力相关的问题，还是用隔离/拆分的思路解决。
基础的服务监控是必须的，CPU、 内存、 磁盘、带宽等基础资源的监控的实现成本不高，但往往能帮我们提前发现问题。
服务的容量评估，是需要好好思考的。对于在线业务，会 Fallback 到 DB 的 Cache 业务，还要小心故障后穿透的风险。
数据相关的经验
准持久化的数据，如果 Redis 没有做好容灾方案，最好前准备全量恢复数据的备案。不然出问题了现写代码就跪了。
要动线上数据的话一定要准备好回滚方案，不然出问题可能就是灾难。
最后说下自主研发的看法，在技术规模达不到的前提下，建议还是利用已有的成熟方案。即便硬性条件达标，要做这件事，也得每一步都非常小心谨慎。
3、前端机扛不住
最后一个问题，前端机的压力问题。
首先，初创公司规模比较小的时候，接入层一般比较少出问题，不过还是建议做好基本的对“坏人”的防范或预案。
再来看前端机集群，我们出过的问题基本可以归为两类。
客户端的轮询出问题，用户对服务端造成大量请求。
后端服务故障，导致前端机处理慢或者干脆连接不上，这样前端机的进程池很容易就打满了。
因为我们已经对服务的资源进行了划分，业务上也有了模块的划分，所以这件事情的处理就相对容易。大概的思路如下。
前端机根据业务分级。核心业务通常变更较少，其他业务变更导致的故障，避免对核心业务有影响。
降级：我们提供了一套降级预案，出问题能立刻通过上线做降级处理，主要有两类策略。
a. 请求端：应对某个用户群或某个业务出问题；
b. 后端服务：某个依赖的后端服务故障。
后端服务容灾：目前 nice 是增加了一层 LVS 来做后端服务的故障切换（针对 MySQL/Redis 内部服务）；另外一点，在前端机应用侧，nice 也做了一层对后端服务的评分机制，避免应用侧才能检测到的问题被忽略掉。
做完上面两个阶段的事情。我们的服务端架构现状大体如下。
nice 现在的痛点和下一步计划
2015 年 8 月之后，经过 RD 和 OP 的共同努力，服务稳定性的问题得到了保障。同时技术团队迅速发展，也有了完整的数据和策略团队的同学。在多方对接的过程中，服务化逐渐就变得越来越重要。
另外，自身团队的规模也在扩大，所有的在线业务代码都在一起，有时候上线一次性要上 10 多个人的变更。代码库的耦合也成了一个明显的问题。
目前 nice 面临的最重要的问题就是服务化和代码拆分。
针对这个问题，我们目前的基本思路如下。
服务化，不一刀切。支持远程调用服务的同时，也能够支持现阶段的同机部署。避免服务过多，过早引入服务管理的问题。
代码拆分，应用开发框架升级。将库/框架/业务剥离，独立维护，并引入库的依赖管理工具。
在参与创业的这一年多时间中。我有非常多的感悟。
创业，是一种生活方式。你随时会面临各种各样的问题，有些是你擅长的，有些是你不擅长的。但是无论如何，你都要挺身而出。因为选择了，就要承担。
本次分享以实际问题为主，希望同样参与创业的朋友，看到这次的分享，能少走一点弯路。
所以就发到php版块了. 如果zuning版主觉得不合适, 请帮忙转移下...
为避免广告嫌疑. 已摘除公司介绍部分.
另外, 分享当时的一些问答, 也没有转过来.
看原文请点下面链接到公众号文章.
去微信公众号阅读原文
现阶段，nice 服务端主要面对以下几方面挑战：
系统设计，面向变化，必须能够很好地支撑“产品探索阶段”需求的多样性。
稳定性，避免稳定性问题对现有用户造成伤害，同时还需要应对业务突发性增长。
协作，麻雀虽小五脏俱全，服务端作为客户端、策略推荐、大数据、QA、运营、产品等各团队的桥梁，如何通过技术或非技术手段解决好各方的桥接。
“推倒重来”：nice 的重构之路
刚加入 nice，我就接到一个极具挑战性的任务，重构服务端整体业务及框架。和很多创业团队一样，我们在成长过程中积累了一系列技术债务。
旧系统是使用 CI 框架编写的，没有模块的划分，没有明确的分层，入口处直接进行各种业务处理，几乎没有复用。
API 的版本管理，是直接目录拷贝，随着业务的发展，已经需要同时维护十多个版本的接口代码，痛苦不堪。
代码中充斥着 if ($isAndroid && $appVersion >= 3) 这样的兼容逻辑。
以至于客户端/服务端联调基本靠喊。我相信初创公司很多朋友都经历过这些问题。
旧系统架构
旧系统架构是一个最典型的一体化的应用架构：后台、 HTML5、接口全部都揉在一起。
面对当时的状况，首先分析要解决的问题，认为下面 3 个问题比较关键。
结构性问题。代码结构混乱，无法复用。
客户端差异管理。接口版本拷贝导致重复代码量巨大，主要针对特定客户端的特殊需求/灰度/小流量等问题。
客户端/服务端 RD 协作问题。
分层和模块化
首先，从大的角度来考虑，可以用简单的两层架构来解决第一个问题。
应用层和服务层在编码层级进行划分：
应用层解决入口的问题，比如交互协议、 鉴权、 Antispam 等通用服务接入以及各端个性化需求。
服务层解决业务逻辑的问题，将服务层按照业务做垂直的模块划分。
通过层次和模块的划分，代码管理变得清晰，逻辑复用性大大提高。同时，业务划分也为后面的业务隔离和分级管理提供了基础支持。
两个基础组件
上述客户端差异管理以及客户端与服务器协作，通过框架的两个基础组件来解决：
ClientAdapter：客户端适配器，用来处理所有客户端差异导致的逻辑问题。
CKCR：CheckAndCorrect，数据的检查和修正，用来控制输入输出协议，解决客户端/服务端 RD 协作的技术层面问题。
ClientAdapter 组件
先来看一个 ClientAdapter 的应用场景。
以上面配置为例，可以实现以下常用的类似规则。
所有客户端为 3.1.0 及以上版本，支持"打招呼"功能。
所有客户端为 3.1.0 以上版本，灰度渠道 abc36032 为 3.1.0 版本，支持"表情"功能。
大家看以上 nice 代码，通过这种方法，逻辑上 nice 应对的是各种 "Feature"，而不是具体的客户端环境。上面例子就是 ClientAdapter 的一种应用场景。
ClientAdapter 的整体结构
ClientAdapter 最基础的部分，是抽象出一个”客户端运行时环境”的概念，用它来描述发起每次请求的客户端的各种信息，比如系统、App 版本、IP、网络制式、 网络运营商、 地理位置等。另外，它提供一种简单的描述规则，用来描述一种受限的客户端环境。
应用层面，它仅对外暴露 checkEnv() 接口，用来检查当前客户端是否满足给定的描述规则。在这个基础设施之上，nice 上层有很多种应用。
比如原本客户端的差异会导致nice面对复杂的客户端适配，通过 NiceFeature，在 Feature 机制下，RD 面对的其实是一个个产品迭代的 Feature。再比如在 NiceUrl 中，nice 中实现了 CDN 的统一调度，通过 ClientAdapter，我们可以灵活控制各个地区使其采用不同的调度策略。
另外，在处理用户分流方面，这套机制所提供的灵活性也能够满足 nice 按照多种维度进行实验用户抽取的需求。
ClientAdapter 开源地址
ClientAdapter 这个组件实现非常简单，只有 200 行。代码已经摘出放在 github 上了，供大家参考，网址为：http://t.cn/RGnqnpj。
补充一点，ClientAdapter 的设计参考了 C 语言中的常用手段。在 autoconf 阶段，将系统的各种环境信息定义为各种各样的 HAVE_XXX 。这样就达到了环境本身的复杂性和实际的业务代码进行解耦的目的。
CKCR 引入
上述问题 3，客户端/服务端 RD 的协作问题，这个问题分两部分。
技术层面：协议层的约束。
流程层面：怎么配合工作。
技术层面上，要解决的问题是怎么让接口协议确保执行。从输入的角度看，我们要不信任客户端，只要协议约定建立就得按规则来，避免客户端被“坏人”控制，对服务造成伤害。从输出的角度看，要将业务层返回的数据确保按照协议约定传输到客户端，避免导致客户端产生不期望的结果，比如常见的类型不 Match 导致 Crash。
一言以蔽之，就是对输入数据的校验和输出数据进行修正。因此，nice 在这里引入了一层叫 CKCR 的组件，全名为 ChecK && CorRect。
CKCR 实现
CKCR 实现了一套很小的描述性语法规则。通过这套语法来描述要对数据进行的校验和修正。校验和修正行为是可以*扩展的，下面是它的一个应用示例。
这个示例中，$data 代表要被处理的数据，$ckcrDesc 就是这个语法规则的描述串。它描述的规则如下。
整体数据是一个 KV 数组（Mapping），只保留 user 和 shows 两个子键的数据。
user 也是一个 KV 数组，它的 id 是 int 类型，name 是 str 类型。
shows 是一个数组，数组中每个元素是一个 KV 数组，过滤掉它的 id 子键，它的 url 子键，应用 imgCdnUrl 的自定义处理（执行 cdn 调度）。
它和 protobuf、Thrift 的 scheme 有相似之处，也有区别。差异主要在于，CKCR 提供的是一种可扩展的数据校验/修正的通用做法。由于这种扩展性，使得它可以对共性数据，在通用层做更多的文章。比如上面例子中的 imgCdnUrl 就是 nice CDN 调度的统一挂接点。
CKCR 内部结构及语法规则
上面是 CKCR 的基础功能。后来在应用中发现，在系统各个场景下，系统核心数据输出的数据结构大部分是一样的。因此，CKCR 描述串的复用性就成为了一个问题。
为了解决这个问题，nice 在 CKCR 编译之前，引入了预处理的机制。可以通过特殊的语法，引用固定的数据结构描述。这个机制引入之后，带来了一个附加的好处，即沉淀系统的核心数据结构。
客户端/服务端协作问题，技术层面 nice 通过这个组件解决。那么，人的协作问题怎么解决?
首先，CKCR 的描述规则是简明的。所以，它可以直接作为接口文档输出。
其次，在接口文档的基础上，nice 服务端和客户端 RD 之间的协作，流程上有一个明确的方案。
定协议：双方 RD 沟通，约定接口协议并提供文档，双方各自进入设计阶段。
假数据：服务端 RD 快速提供 Mock 数据的伪接口，供客户端 RD 基础功能自测使用。
真接口：服务端 RD 提供真实接口，双方联调。
这样分步的开发方式，基本就解决掉了”联调靠喊”的问题。双方的工作基本解耦，并且也基本不影响双方的开发进度。
CKCR 开源地址
CKCR 这个组件的源代码，已经摘出来放在 github 上了，网址为：http://t.cn/RGn57Xk。
第一阶段总结
上面这些就是 nice 应对第一阶段 3 个问题的方案：
分层和模块化：通过两层架构，解决掉结构性问题。
客户端适配器：解决掉客户端差异的问题。
CKCR：通过 CKCR 及协作流程，解决掉客户端/服务端 RD 协作的问题。
这个阶段，主要通过整体的重构，解决掉开发的问题，同时为未来的架构调整铺平路。
当时的做法是”推倒重来”，现在回顾，这种选择就当时的情况来说是正确的。在那个时间前后，我们没重构系统所遗留的问题，在系统变得更加庞大之后，变得更加棘手。
不过，话说回来，“推倒重来”的重构之路，毕竟还是充满了各种风险的，做这样的决定前，一定要做好充分的资源和风险评估。
为稳定性填的那些坑
在完成整体性的重构之后，nice 进入了业务的快速开发。2015 年 3 月还搞了一个月的 SpeciaForce，研发团队几乎所有人都住公司附近，7 * 14 小时以上的工作量。那段时间的冲刺，为我们的产品带来了日活等关键数据的提升，接口 PV 也达到了最高峰的 5 亿/天。
直到 2015 年 8 月，服务的稳定性经受了很大的考验，说实在的，我当时都快崩溃了，最重要的几类问题如下。
1、MySQL 扛不住
nice 的 MySQL 集群最初就是单实例单库，一主四从，机械硬盘。2015 年 4 月，跟很多业务增长很快的团队一样，为了快速解决问题，OP 把所有的 DB 都换成 SSD，收益非常大。
另外，由于考虑单库导致服务无法隔离，主库的写入也成为瓶颈。2015 年 3 月左右，nice 开始着手考虑分库/分表的事情。分库的方案，主要按垂直的业务进行划分。
技术债真是欠不得！！！
分库整个耗费了两位同学差不多半年的时间。接下来又用了大概一个季度的时间，针对系统的核心大表，进行表的拆分。
在 MySQL 这块儿，我们的教训如下。
用硬件解决问题，性价比非常高。
库的业务线划分，表的规模评估，这样的事情，千万马虎不得。提前做可能多几人天；拖后做可能就像我们需要甚至超过 1 人年的时间去擦屁股。
另外一方面，nice 对 Redis 的依赖也是很重的。一部分数据，是典型的 Cache用法。在线业务访问 Cache 没有的时候，会自动 fallback 到 DB，去冲 Cache。另外一部分数据，是准持久化数据。这部分我们在线业务不会 fallback 到 DB。
2、Redis 扛不住
nice 的 Redis 也是单集群。大概 2015 年四五月的时候，随着业务的快速迭代，很多新功能上线，Redis 的压力迅速增大，开始偶尔出现 Redis 故障。那个时候，nice 就开始了 Redis 的服务拆分。因为业务模式比较简单，所以 Redis的拆分速度是比较快的。
但同时，由于故障中丢过数据，我们决定在 Redis 高可用方面做一些自主开发。主要是针对平滑扩容、 故障自动切换等方面。
由于这方面经验并不是很足，导致出了不小的问题。最严重的一次，上线试运行阶段没有发现问题，但切到全量后，多个集群节点接连出现问题。硬扛了两天左右，最后扛不住，只得往回切换。然而，当时又面临机器资源的问题，做不到一次性全量切回，只能逐集群切换，同时搭上几个 RD 去写几乎所有的准持久化数据的恢复脚本。
Redis 这块儿的教训是非常惨痛的，从 2015 年的踩坑经历来看，我们的收获是如下。
压力与容量评估的经验
压力相关的问题，还是用隔离/拆分的思路解决。
基础的服务监控是必须的，CPU、 内存、 磁盘、带宽等基础资源的监控的实现成本不高，但往往能帮我们提前发现问题。
服务的容量评估，是需要好好思考的。对于在线业务，会 Fallback 到 DB 的 Cache 业务，还要小心故障后穿透的风险。
数据相关的经验
准持久化的数据，如果 Redis 没有做好容灾方案，最好前准备全量恢复数据的备案。不然出问题了现写代码就跪了。
要动线上数据的话一定要准备好回滚方案，不然出问题可能就是灾难。
最后说下自主研发的看法，在技术规模达不到的前提下，建议还是利用已有的成熟方案。即便硬性条件达标，要做这件事，也得每一步都非常小心谨慎。
3、前端机扛不住
最后一个问题，前端机的压力问题。
首先，初创公司规模比较小的时候，接入层一般比较少出问题，不过还是建议做好基本的对“坏人”的防范或预案。
再来看前端机集群，我们出过的问题基本可以归为两类。
客户端的轮询出问题，用户对服务端造成大量请求。
后端服务故障，导致前端机处理慢或者干脆连接不上，这样前端机的进程池很容易就打满了。
因为我们已经对服务的资源进行了划分，业务上也有了模块的划分，所以这件事情的处理就相对容易。大概的思路如下。
前端机根据业务分级。核心业务通常变更较少，其他业务变更导致的故障，避免对核心业务有影响。
降级：我们提供了一套降级预案，出问题能立刻通过上线做降级处理，主要有两类策略。
a. 请求端：应对某个用户群或某个业务出问题；
b. 后端服务：某个依赖的后端服务故障。
后端服务容灾：目前 nice 是增加了一层 LVS 来做后端服务的故障切换（针对 MySQL/Redis 内部服务）；另外一点，在前端机应用侧，nice 也做了一层对后端服务的评分机制，避免应用侧才能检测到的问题被忽略掉。
做完上面两个阶段的事情。我们的服务端架构现状大体如下。
nice 现在的痛点和下一步计划
2015 年 8 月之后，经过 RD 和 OP 的共同努力，服务稳定性的问题得到了保障。同时技术团队迅速发展，也有了完整的数据和策略团队的同学。在多方对接的过程中，服务化逐渐就变得越来越重要。
另外，自身团队的规模也在扩大，所有的在线业务代码都在一起，有时候上线一次性要上 10 多个人的变更。代码库的耦合也成了一个明显的问题。
目前 nice 面临的最重要的问题就是服务化和代码拆分。
针对这个问题，我们目前的基本思路如下。
服务化，不一刀切。支持远程调用服务的同时，也能够支持现阶段的同机部署。避免服务过多，过早引入服务管理的问题。
代码拆分，应用开发框架升级。将库/框架/业务剥离，独立维护，并引入库的依赖管理工具。
在参与创业的这一年多时间中。我有非常多的感悟。
创业，是一种生活方式。你随时会面临各种各样的问题，有些是你擅长的，有些是你不擅长的。但是无论如何，你都要挺身而出。因为选择了，就要承担。
本次分享以实际问题为主，希望同样参与创业的朋友，看到这次的分享，能少走一点弯路。
回复讨论(解决方案)
学习一下，好东西！
完全看不明白
支持！！！！
有些看不懂，看来还有很多要学的
有点看不懂
写的 还是蛮不错的