《高可用架构第1卷【1】》——高可用架构案例精选

如何使用日志在Manhattan（Twitter 的最终一致性分布式 KV数据库）中实现 compare-and-set CAS这样的强一致性操做redis

用日志来序列化全部请求；算法

到此为止，你能够看出日志的好处。它将一个本来复杂的问题变得简单。

这种解决问题的思路叫作 Pub/Sub。而日志就是 Pub/Sub 模式的基础。

由于 Pub/Sub 这个模式是那么简单并且强有力，这让咱们思考，是否是能够构建一个高可用的分布式日志服务，全部在 Twitter 的分布式系统均可以复用这个日志服务？

构建一个分布式日志系统，首要的事情就是找出咱们须要解决什么问题，知足什么样的需求。sql

首先做为一个基本设施，存储在日志中的数据须要持久化，这样它能够容忍宕机，避免数据丢失。数据库

由于须要做为分布式系统的基础设施，那么在单机上持久化是远远不够的。咱们须要将数据复制到多台机器上，提升数据和系统的可用性。后端

当数据被复制到多台机器上的时候，咱们就须要保证数据的强一致性。不然，若是咱们出现丢数据、数据不一致，那么势必影响到构建在分布式日志上的全部系统。若是日志都不能相信了，你的生活还能相信谁呢 ：）api

 持久化 多副本 一致性

在设计这个分布式日志系统 DistributedLog 的时候，咱们进行了各类调研。也同时基于运维已有系统 (kestrel, Kafka) 的经验，咱们最终决定基于 Apache BookKeeper进行构建。

主要由于 Apache BookKeeper 提供的三个核心特性：I/O 分离、并行复制和容易理解的一致性模型。它们可以很好地知足咱们对于持久化、多副本和一致性的要求。

Apache BookKeeper 没有将很复杂的一致性机制捆绑在一块儿。写者和读者之间也没有很复杂的协同机制。全部的一致性的协调就是经过这个 LAC 指针 (Last Add Confirmed)。这样的作法，能够使得扩展写者和扩展读者相互分离。

Q & A
一、日志顺序方面，日志的序列号（1,2,3,4……），是否使用了 Twitter 的 snowflake 服务？获取序列号后再推送日志？是上面提到的什么组件作的？

没有使用 Twitter 的 snowflake 服务。由于 Writer 是 single writer，存在 ownership。全部的写会 forward 给 owner 进行序列化。

二、这是 Kafka 的替代产品吗？

是的。Kafka 目前没有被使用在数据库日志的场景。由于 Kafka 的每一个 topic 对应一个文件，在 topic 数量特别多，且须要持久化的场景，Kafka 的性能比较差。很难适用于 Twitter 的多租户场景。

三、请问是否研究过 ELK，请问在前面分享的架构中，哪一个对应 ELK 中的 Logstash（或fluentd）部分？或是 BookKeeper 就是替换它的？

这里的日志就是数据库的日志。跟平常的文本日志不同。在 ELK 架构中，E 是文本的索引，K 是 UI。这两个部分不是 DistributedLog/BookKeeper 所解决的问题。DistributedLog/BookKeeper 能够做为 PUB/SUB 这样的消息中间件来作日志的中转，也就是能够用在 L 的部分。

四、分享中提到的 Kestrel 和 Kafka 一个在线 ，一个离线，具体差别是什么？

Kestrel 主要是 producer/consumer queue 的模型。而 Kafka 是 pub/sub 模型。Kestrel 支持 per item 的 transaction，粒度是 item。而 Kafka 的粒度是 partition。

五、Name Log 的具体机制是什么样的？ Client 删除日志时怎样保证与读者和写者不冲突？

Name Log 是 DistributedLog 提供的用户接口。底层分块成不一样的 Ledgers 进行存储。元数据记录在 ZooKeeper。使用 ZooKeeper 的 CAS 操做和 notification 机制来协调。

六、想多了解一下跨数据中心复制，感受很差作。能否介绍一下？

这个问题比较宽泛。跨数据中心，能够是异步复制，也能够是同步复制。不一样场景有不一样的权衡。

七、若是 LAC 以后的那条记录始终不能写成功，是否是就阻塞在那里，LAC 就无法移动了？

这是一个很好的问题。Ensemble Change 可以保证写永远 go through。因此 LAC 会被 update 到 bookies。读方面的 Speculative 机制保证能读到 LAC。

八、 这里的 writer 是 Write Proxy 吗？若是是的话，single writer 的吞吐量就是这个 ledger 的最大写的吞吐量了吧，会不会成为瓶颈？

这里的 Writer 是指 Write Proxy。首先，一个 Ledger 的吞吐量，取决于 Bookie 的磁盘/网络带宽。假设，Bookie 的网卡是 1Gbps，一块磁盘做为日志写的磁盘，那么在保证低延时的状况下，Bookie 的吞吐能够达到 50MB/s~70MB/s。在 BookKeeper，能够经过配置 Ledger 的 Ensemble Size, Write Quorum Size 和 Ack Quorum Size，经过 Stripping 写的方式来提升 Ledger 的吞吐。好比，设置 Ensemble Size 为 6， Write Quorum Size 为 3， Ack Quorum Size 为 2。那么吞吐量能够提升到 2 倍。这是 Ledger 内的 Scalability。

九、 Failover 到其余 Proxy Server 时，如何继续产生递增的 Entry ID？
在 failover 到其余 Proxy Server 时，DistributedLog 并不会复用上一个 Proxy Server 的 ledger。因此 failover 以后，它会关闭上个 Proxy Server 写的 ledger，而后从新开一个 ledger 进行写入。递增的 Entry ID 是基于当前 ledger 生成的。从整个日志的角度来看，<ledger id, entry id> 构成了 unique 的记录 ID。若是对于 consensus 算法有所了解，可能会知道 `epoch` 的概念。每一个 epoch 会有一个 designated 的 leader。而在 DistributedLog 中，`ledger id` 其实扮演着 `epoch` 的概念。
————————————————
版权声明：本文为CSDN博主「高可用架构」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。
原文连接：https://blog.csdn.net/weixin_45583158/article/details/100142918

二、矩阵式逻辑框架

咱们以黑分类器为例来剖析下分类器的整个逻辑框架。

总的来说咱们采用了矩阵式的逻辑框架，最开始的黑分类器咱们也是一把抓，随意的创建一个个针对黑产的检测规则、模型。

结果发现不是这个逻辑漏过了，而是那个逻辑误伤量大，要对那一类的帐号增强安全打击力度，改动起来也很是麻烦。

所以咱们就设计了这个一个矩阵式的框架来解决上述问题。

矩阵的横向采用了Adaboost方法，该方法是一种迭代算法，其核心思想是针对同一个训练集训练不一样的弱分类器，而后把这些分类器集合起来，构成一个最终的分类器。

而咱们这里每个弱分类器都只能解决一种账号类型的安全风险判断，集中起来才能解决全部帐户的风险检测。

那么在工程实践上带来三个好处：

1. 便于实现轻重分离，好比某平台虚假帐号集中在邮箱帐号，策略就能够加大对邮箱帐号的打击力度，影响范围也局限在邮箱账号，而不是该平台全部的帐号。

2. 减小模型训练的难度，模型训练最大的难度在于样本的均衡性问题，拆分红子问题，就不须要考虑不一样帐号类型之间的数据配比、均衡性问题，大大下降了模型训练时正负样本比率的问题。

3. 逻辑的健壮性，某一个分类器的训练出现了问题，受影响的范围不至于扩展到全局。

矩阵纵向采用了Bagging方法，该方法是一种用来提升学习算法准确度的方法，该方法在同一个训练集合上构造预测函数系列，而后以必定的方法将他们组合成一个预测函数，从而来提升预测结果的准确性。

360消息系统介绍

360消息系统更确切的说是长链接push系统，目前服务于360内部多个产品，开发平台数千款app，也支持部分聊天业务场景，单通道多app复用，支持上行数据，提供接入方不一样粒度的上行数据和用户状态回调服务。

 

目前整个系统按不一样业务分红9个功能完整的集群，部署在多个idc上（每一个集群覆盖不一样的idc），实时在线数亿量级。一般状况下，pc，手机，甚至是智能硬件上的360产品的push消息，基本上是从咱们系统发出的。

关于push系统对比与性能指标的讨论

不少同行比较关心go语言在实现push系统上的性能问题，单机性能究竟如何，可否和其余语言实现的相似系统作对比么？甚至问若是是创业,第三方云推送平台，推荐哪一个?

其实各大厂都有相似的push系统，市场上也有相似功能的云服务。包括咱们公司早期也有erlang，nodejs实现的相似系统，也一度被公司要求作相似的对比测试。我感受在讨论对比数据的时候，很难保证你们环境和需求的统一，我只能说下我这里的体会，数据是有的，但这个数据前面估计会有不少定语~

第一个重要指标：单机的链接数指标

作过长链接的同行，应该有体会，若是在稳定链接状况下，链接数这个指标，在没有网络吞吐状况下对比，其实意义每每不大，维持链接消耗cpu资源很小，每条链接tcp协议栈会占约4k的内存开销，系统参数调整后，咱们单机测试数据，最高也是能够达到单实例300w长链接。但作更高的测试，我我的感受意义不大。

由于实际网络环境下，单实例300w长链接，从理论上算压力就很大：实际弱网络环境下，移动客户端的断线率很高，假设每秒有1000分之一的用户断线重连。300w长链接，每秒新建链接达到3w，这同时连入的3w用户，要进行注册，加载离线存储等对内rpc调用，另外300w长链接的用户心跳须要维持,假设心跳300s一次，心跳包每秒须要1w tps。单播和多播数据的转发，广播数据的转发，自己也要响应内部的rpc调用，300w长链接状况下，gc带来的压力，内部接口的响应延迟可否稳定保障。这些集中在一个实例中，可用性是一个挑战。因此线上单实例不会hold很高的长链接,实际状况也要根据接入客户端网络情况来决定。

第二个重要指标:消息系统的内存使用量指标

这一点上，使用go语言状况下，因为协程的缘由，会有一部分额外开销。可是要作两个推送系统的对比，也有些须要肯定问题。好比系统从设计上是否须要全双工（即读写是否须要同时进行）若是半双工，理论上对一个用户的链接只须要使用一个协程便可（这种状况下，对用户的断线检测可能会有延时），若是是全双工，那读/写各一个协程。两种场景内存开销是有区别的。

另外测试数据的大小每每决定咱们对链接上设置的读写buffer是多大，是全局复用的，仍是每一个链接上独享的，仍是动态申请的。另外是否全双工也决定buffer怎么开。不一样的策略，可能在不一样状况的测试中表现不同。

第三个重要指标：每秒消息下发量

这一点上，也要看咱们对消息到达的QoS级别(回复ack策略区别），另外看架构策略，每种策略有其更适用的场景，是纯粹推？仍是推拉结合？甚至是否开启了消息日志？日志库的实现机制、以及缓冲开多大？flush策略……这些都影响整个系统的吞吐量。

另外为了HA，增长了内部通讯成本，为了不一些小几率事件，提供闪断补偿策略，这些都要考虑进去。若是全部的都去掉，那就是比较基础库的性能了。

因此我只能给出大概数据，24核，64G的服务器上，在QoS为message at least，纯粹推，消息体256B~1kB状况下，单个实例100w实际用户（200w+）协程，峰值能够达到2~5w的QPS...内存能够稳定在25G左右，gc时间在200~800ms左右（还有优化空间）。

咱们正常线上单实例用户控制在80w之内，单机最多两个实例。事实上，整个系统在推送的需求上，对高峰的输出不是提速，每每是进行限速，以防push系统瞬时的高吞吐量，转化成对接入方业务服务器的ddos攻击因此对于性能上，我感受你们能够放心使用，至少在咱们这个量级上，经受过考验，go1.5到来后，确实有以前投资又增值了的感受。

关于推送的服务端架构

常见的推送模型有长轮训拉取，服务端直接推送（360消息系统目前主要是这种），推拉结合（推送只发通知，推送后根据通知去拉取消息）.

拉取的方式不说了，如今并不经常使用了，早期不少是nginx+lua+redis，长轮训，主要问题是开销比较大，时效性也很差，能作的优化策略很少。

直接推送的系统，目前就是360消息系统这种，消息类型是消耗型的，而且对于同一个用户并不容许重复消耗,若是须要多终端重复消耗，须要抽象成不一样用户。

推的好处是实时性好，开销小，直接将消息下发给客户端，不须要客户端走从接入层到存储层主动拉取.

但纯推送模型，有个很大问题，因为系统是异步的，他的时序性没法精确保证。这对于push需求来讲是够用的，但若是复用推送系统作im类型通讯，可能并不合适。

对于严格要求时序性，消息能够重复消耗的系统，目前也都是走推拉结合的模型，就是只使用咱们的推送系统发通知，并附带id等给客户端作拉取的判断策略，客户端根据推送的key，主动从业务服务器拉取消息。而且当主从同步延迟的时候，跟进推送的key作延迟拉取策略。同时也能够经过消息自己的QoS，作纯粹的推送策略，好比一些“正在打字的”低优先级消息，不须要主动拉取了，经过推送直接消耗掉。

哪些因素决定推送系统的效果？

首先是sdk的完善程度，sdk策略和细节完善度，每每决定了弱网络环境下最终推送质量.

SDK选路策略,最基本的一些策略以下：有些开源服务可能会针对用户hash一个该接入区域的固定ip，实际上在国内环境下不可行，最好分配器（dispatcher）是返回散列的一组，并且端口也要参开，必要时候，客户端告知是retry多组都连不上，返回不一样idc的服务器。由于咱们会常常检测到一些case，同一地区的不一样用户，可能对同一idc内的不一样ip连通性都不同，也出现过同一ip不一样端口连通性不一样，因此用户的选路策略必定要灵活，策略要足够完善.另外在选路过程当中，客户端要对不一样网络状况下的长链接ip作缓存，当网络环境切换时候（wifi、2G、3G)，从新请求分配器，缓存不一样网络环境的长链接ip。

客户端对于数据心跳和读写超时设置,完善断线检测重连机制

针对不一样网络环境，或者客户端自己消息的活跃程度，心跳要自适应的进行调整并与服务端协商，来保证链路的连通性。而且在弱网络环境下，除了网络切换（wifi切3G）或者读写出错状况，何时从新创建链路也是一个问题。客户端发出的ping包，不一样网络下，多久没有获得响应，认为网络出现问题，从新创建链路须要有个权衡。另外对于不一样网络环境下，读取不一样的消息长度，也要有不一样的容忍时间，不能一刀切。好的心跳和读写超时设置，可让客户端最快的检测到网络问题，从新创建链路，同时在网络抖动状况下也能完成大数据传输。

几个大概重要组件介绍以下：

dispatcher service 根据客户端请求信息，将应网络和区域的长链接服务器的，一组IP传送给客户端。客户端根据返回的IP，创建长链接，链接Room service.

room Service，长链接网关，hold用户链接，并将用户注册进register service，自己也作一些接入安全策略、白名单、IP限制等。

register service 是咱们全局session存储组件，存储和索引用户的相关信息，以供获取和查询。

coordinator service 用来转发用户的上行数据，包括接入方订阅的用户状态信息的回调，另外作须要协调各个组件的异步操做，好比kick用户操做,须要从register拿出其余用户作异步操做.

saver service是存储访问层，承担了对redis和mysql的操做，另外也提供部分业务逻辑相关的内存缓存，好比广播信息的加载能够在saver中进行缓存。另一些策略，好比客户端sdk因为被恶意或者意外修改，每次加载了消息，不回复ack，那服务端就不会删除消息，消息就会被反复加载，造成死循环，能够经过在saver中作策略和判断。（客户端老是不可信的）。

center service 提供给接入方的内部api服务器，好比单播或者广播接口，状态查询接口等一系列api,包括运维和管理的api。

举两个常见例子，了解工做机制：好比发一条单播给一个用户，center先请求Register获取这个用户以前注册的链接通道标识、room实例地址，经过room service下发给长链接Center Service比较重的工做如全网广播，须要把全部的任务分解成一系列的子任务，分发给全部center，而后在全部的子任务里，分别获取在线和离线的全部用户，再批量推到Room Service。一般整个集群在那一瞬间压力很大。

deployd/agent service 用于部署管理各个进程，收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度

结合服务端作策略

另外系统可能结合服务端作一些特殊的策略，好比咱们在选路时候，咱们会将同一个用户尽可能映射到同一个roomservice实例上。断线时，客户端尽可能对上次链接成功的地址进行重试。主要是方便服务端作闪断状况下策略，会暂存用户闪断时实例上的信息，从新连入的时候，作单实例内的迁移，减小延时与加载开销.

客户端保活策略

不少创业公司愿意从新搭建一套push系统，确实不难实现，其实在协议完备状况下（最简单就是客户端不回ack不清数据），服务端会保证消息是不丢的。但问题是为何在消息有效期内,到达率上不去？每每由于本身app的pushservice存活能力不高。选用云平台或者大厂的，每每sdk会作一些保活策略，好比和其余app共生，互相唤醒，这也是云平台的pushservice更有保障缘由。我相信不少云平台旗下的sdk，多个使用一样sdk的app，为了实现服务存活，是能够互相唤醒和保证活跃的。另外如今push sdk自己是单链接，多app复用的，这为sdk实现，增长了新的挑战。

综上，对我来讲，选择推送平台，优先会考虑客户端sdk的完善程度。对于服务端，选择条件稍微简单，要求部署接入点（IDC）越要多，配合精细的选路策略，效果越有保证，至于想知道哪些云服务有多少点，这个群里来自各地的小伙伴们，能够合伙测测。

当时出现问题，如今总结起来，大概如下几点

1.散落在协程里的I/O，Buffer和对象不复用。

当时（12年）因为对go的gc效率理解有限，比较奔放，程序里大量short live的协程，对内通讯的不少io操做，因为不想阻塞主循环逻辑或者须要及时响应的逻辑，经过单独go协程来实现异步。这回会gc带来不少负担。

针对这个问题，应尽可能控制协程建立，对于长链接这种应用，自己已经有几百万并发协程状况下，不少状况不必在各个并发协程内部作异步io，由于程序的并行度是有限，理论上作协程内作阻塞操做是没问题。

若是有些须要异步执行，好比若是不异步执行，影响对用户心跳或者等待response没法响应，最好经过一个任务池，和一组常驻协程，来消耗，处理结果，经过channel再传回调用方。使用任务池还有额外的好处，能够对请求进行打包处理，提升吞吐量，而且能够加入控量策略.

2.网络环境很差引发激增

go协程相比较以往高并发程序，若是作很差流控，会引发协程数量激增。早期的时候也会发现，时不时有部分主机内存会远远大于其余服务器，但发现时候，全部主要profiling参数都正常了。

后来发现，通讯较多系统中，网络抖动阻塞是不可免的(即便是内网)，对外不停accept接受新请求，但执行过程当中，因为对内通讯阻塞，大量协程被建立，业务协程等待通讯结果没有释放，每每瞬时会迎来协程暴涨。但这些内存在系统稳定后，virt和res都并没能完全释放，降低后，维持高位。

处理这种状况，须要增长一些流控策略，流控策略能够选择在rpc库来作，或者上面说的任务池来作，其实我感受放在任务池里作更合理些，毕竟rpc通讯库能够作读写数据的限流，但它并不清楚具体的限流策略，究竟是重试仍是日志仍是缓存到指定队列。任务池自己就是业务逻辑相关的，它清楚针对不一样的接口须要的流控限制策略。

3.低效和开销大的rpc框架

早期rpc通讯框架比较简单，对内通讯时候使用的也是短链接。这原本短链接开销和性能瓶颈超出咱们预期，短链接io效率是低一些，但端口资源够，自己吞吐能够知足须要，用是没问题的，不少分层的系统，也有http短链接对内进行请求的

但早期go版本，这样写程序，在必定量级状况，是支撑不住的。短链接大量临时对象和临时buffer建立，在本已经百万协程的程序中，是没法承受的。因此后续咱们对咱们的rpc框架做了两次调整。

第二版的rpc框架，使用了链接池，经过长链接对内进行通讯（复用的资源包括client和server的：编解码Buffer、Request/response），大大改善了性能。

但这种在一次request和response仍是占用链接的，若是网络情况ok状况下，这不是问题，足够知足须要了，但试想一个room实例要与后面的数百个的register，coordinator，saver，center，keeper实例进行通讯，须要创建大量的常驻链接，每一个目标机几十个链接，也有数千个链接被占用。

非持续抖动时候（持续逗开多少无解），或者有延迟较高的请求时候，若是针对目标ip链接开少了，会有瞬时大量请求阻塞，链接没法获得充分利用。第三版增长了Pipeline操做，Pipeline会带来一些额外的开销，利用tcp的全双特性，以尽可能少的链接完成对各个服务集群的rpc调用。

4.Gc时间过长

Go的Gc仍旧在持续改善中，大量对象和buffer建立，仍旧会给gc带来很大负担，尤为一个占用了25G左右的程序。以前go team的大咖邮件也告知咱们，将来会让使用协程的成本更低，理论上不须要在应用层作更多的策略来缓解gc.

改善方式，一种是多实例的拆分，若是公司没有端口限制，能够很快部署大量实例，减小gc时长，最直接方法。不过对于360来讲，外网一般只能使用80和433。所以常规上只能开启两个实例。固然不少人给我建议可否使用SO_REUSEPORT，不过咱们内核版本确实比较低，并无实践过。

另外可否模仿nginx，fork多个进程监控一样端口，至少咱们目前没有这样作，主要对于咱们目前进程管理上，仍是独立的运行的，对外监听不一样端口程序，还有配套的内部通讯和管理端口，实例管理和升级上要作调整。

解决gc的另两个手段，是内存池和对象池,不过最好作仔细评估和测试，内存池、对象池使用，也须要对于代码可读性与总体效率进行权衡。

这种程序必定状况下会下降并行度，由于用池内资源必定要加互斥锁或者原子操做作CAS，一般原子操做实测要更快一些。CAS能够理解为可操做的更细行为粒度的锁（能够作更多CAS策略，放弃运行，防止忙等）。这种方式带来的问题是，程序的可读性会愈来愈像C语言，每次要malloc，各地方用完后要free，对于对象池free以前要reset，我曾经在应用层尝试作了一个分层次结构的“无锁队列”

上图左边的数组其实是一个列表，这个列表按大小将内存分块，而后使用atomic操做进行CAS。但实际要看测试数据了，池技术能够明显减小临时对象和内存的申请和释放，gc时间会减小，但加锁带来的并行度的下降，是否能给一段时间内的总体吞吐量带来提高，要作测试和权衡…

在咱们消息系统，实际上后续去除了部分这种黑科技，试想在百万个协程里面作自旋操做申请复用的buffer和对象，开销会很大，尤为在协程对线程多对多模型状况下，更依赖于golang自己调度策略，除非我对池增长更多的策略处理，减小忙等，感受是在把runtime作的事情，在应用层很是不优雅的实现。广泛使用开销理论就大于收益。

但对于rpc库或者codec库，任务池内部，这些开定量协程，集中处理数据的区域，能够尝试改造~

对于有些固定对象复用，好比固定的心跳包什么的，能够考虑使用全局一些对象，进行复用，针对应用层数据，具体设计对象池，在部分环节去复用，可能比这种无差异的设计一个通用池更能进行效果评估.

消息系统的运维及测试

下面介绍消息系统的架构迭代和一些迭代经验，因为以前在其余地方有过度享，后面的会给出相关连接，下面实际作个简单介绍，感兴趣能够去连接里面看

架构迭代~根据业务和集群的拆分，能解决部分灰度部署上线测试，减小点对点通讯和广播通讯不一样产品的相互影响，针对特定的功能作独立的优化.

消息系统架构和集群拆分，最基本的是拆分多实例，其次是按照业务类型对资源占用状况分类，按用户接入网络和对idc布点要求分类（目前没有条件，全部的产品都部署到所有idc）

四. 聊聊关于架构优化的一些总结和感想

在各类场合常常据说的架构优化，通常都是优化某一个具体的业务模块，将性能优化到极致。而在雪球，咱们作的架构优化更多的是从问题出发，解决实际问题，解决到能够接受的程度便可。可能你们看起来会以为很凌乱，并且每一个事情单独拎出来好像都不是什么大事。

咱们在对一个大服务作架构优化时，通常是往深刻的本质进行挖掘；当咱们面对一堆架构各异的小服务时，“架构优化”的含义实际上是有一些不同的。大部分时候，咱们并不须要（也没有办法）深刻到小服务的最底层进行优化，而是去掉或者优化原来明显不合理的地方就能够了。

在快速迭代的创业公司，咱们可能不会针对某一个服务作很完善的架构设计和代码实现，当出现各类问题时，也不会去追求极致的优化，而是以解决瓶颈问题为先。

即便咱们经历过一回将 snowball 拆分服务化的过程，但当咱们从新上一个新的业务时，咱们依然选择将它作成一个大一统的服务。只是这一次，咱们会提早定义好每一个模块的 service 接口，为之后可能的服务化铺好路。

在创业公司里，重写是不能接受的；大的重构，从时间和人力投入上看，通常也是没法承担的。而“裱糊匠”式作法，哪里有性能问题就加机器，加缓存，加数据库，有可用性问题就加剧试，加log，出故障就加流程，加测试，这也不是雪球团队工做方式。咱们通常都采用最小改动的方式，即，准肯定义问题，定位问题根源，找到问题本质，制定最佳方案，以最小的改动代价，将问题解决到可接受的范围内。

咱们如今正在全部的地方强推3个数据指标：qps，p99，error rate。每一个技术人员对本身负责的服务，必定要有最基本的数据指标意识。数字，是发现问题，定位根源，找到本质的最重要的依赖条件。没有之一。

咱们的原则：保持技术栈的一致性和简单性，有节制的尝试新技术，保持全部线上服务依赖的技术可控，简单来讲，能 hold 住。

能用cache的地方毫不用db，能异步的地方，毫不同步。俗称的：吃一堑，长一智。

特事特办：业务在发展，需求在变化，实现方式也须要跟着变化。简单的来讲：遗留系统的优化，最佳方案就是砍需求，呵呵。

当前，雪球内部正在推行每一个模块的方案和代码实现的 review，在 review 过程当中，我通常是这样要求的：

技术方案：

• 20倍设计，10倍实现，3倍部署

• 扩展性：凡事留一线，之后好相见

技术实现：

• DevOps：上线后仍是你本身维护的项目，实现的时候记得考虑各类出错的处理

• 用户投诉的时候须要你去解释，实现的时候注意各类边界和异常

• 快速实现，不是“随便实现”，万一火了呢：性能，方便扩容