系统设计思考

系统设计思考
发表于 2015 年 6 月 6 日

读了微信架构描述后的一点思考

模块拆分：设计大系统，一定要拆分子系统，模块，项目，做到各项目间相互独立。在较小的系统设计中一般将模块划分清晰即可了，甚至是在一个进程之内，大一点在一台物理机上多进程实现，但在海量系统设计中，本身就是分布式的系统设计。不但要将其逻辑分离，还要注意其物理的分离，微信中登录状态服务器，LBS服务器，支付系统，摇一摇系统均为独立的服务器。很多互联网服务的设计，都注意将用户登录，后端不同业务都互相分开，这样一来各系统都可独立研发与部署。但在更新版本时务必注意系统间接口的兼容性。

扩展性：这里的扩展性，一是指协议的扩展，二是指数据存储的扩展，个人认为还包括处理能力的扩展。互联网业务一个特点便是技术日新月异，每个想法都可变为现实。一个负责文字通信的IM，增加语音与视频的支持，需要修改协议。朋友圈业务的增加也涉及协议，后来有的钱包等各种业务无一不涉及通信协议的变化。通信协议不光设计客户端服务器之间，如果服务器之间不同业务的交互接口看作协议的话，其实也都涉及扩展性及兼容性的问题。笔者从事多年的radius/diameter/eap等协议，虽然是传统通信的协议，其均具有非常良好的扩展性。关于数据存储方面，在NOSQL之前，都是基于固定字段的存储方式，但随着互联网业务的发展，各种业务产生的字段/列数量巨大，且大部分可能取值为空，目前主要用的KV，列存储等NOSQL存储了。关于处理能力的扩展，则涉及负载均衡，缓存，模块数量变化时一致性哈希选择模块等问题

快速部署：一个系统的上线，很难想象没有监控时是怎样的，必须有良好的各系统运行状态的监控系统。为了快速迭代，还要有良好的快速代码部署组件。

灰度发布：跟上述的代码部署也相关联。发布时先让一部分用户切换到新系统，慢慢扩充用户范围。

容灾：一个系统可以分成接入层，逻辑层，存储层。接入层与逻辑层的容灾非常成熟，在逻辑层，尽量使用无状态的设计，这样消息到达后可随意切换服务器，在哪里处理都一样。笔者的AAA服务器在涉及多步交互时，为了性能考虑则必须将交互中间的信息存储到内存中，这便是有状态的设计了，这么一来消息分发到其他模块必然无法接续。但是如果使用存储系统，性能又受影响。只能权衡。

好的系统一定是简单的，处理海量数据的系统允许存在一定的短时数据不一致性， 如果验收标准成了严格的一致性，系统必将复杂很多很多。