如何做好架构
①需求优化最重要：一个IT系统是多角色多模块分层分级的，像OSI模型上层应用简单依赖下层支撑，SOA设计中同级角色也只看对方的接口。各角色分工明确方便快速实现业务，这给架构优化带来很大问题，前端一个小逻辑需求会导致后端大规模联动，不同服务也没权限理解对方的内存数据，各个角色只能局限于自己的工作范围。架构设计最重要就是需求，删减上层应用的需求优化（前端对后端少输入少查询多容错），同级的业务可以互相容错（应用间的需求优化，例如两个系统可以好解耦，不会发生A系统等到B系统等到死锁的情况）。
②群集设计通用规则：前端复制后端拆，实时改异步，三组件（IO和CPU和空间）互换，架构的另一个存在即时群集。
前端是管道是逻辑，而后端是状态是数据，所以前端复制后端拆。前端服务器压力大了就多做水平复制扩容，在网站类应用上，无状态-会话保持-弹性伸缩等技术应用纯熟。后端要群集化就是多做业务拆分，常见的就是数据库拆库拆表拆键值，服务拆的越散微操作就越爽，但全局操作开销更大更难控制。
绝大部分“实时操作”都不是业务需求。而是某应用无法看到后端和Peer状态，默认就要实时处理结果了。CS模式的实时操作会给支撑服务带来巨大压力，Peer合作的实时操作可能会让数据申请方等很久。架构师将大事务拆分成小事务，这就是异步架构，拆散的小事务需要更高业务层级上做全局事务保障。
群集性能规划中，网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的，数据压缩技术就是用算力资源来置换IO和空间，缓存技术是用空间和IO来缓解算力压力，每个新选型都会带来细节上的万千变化，但是这种变化是符合自然规律有章可循的。一个经典微机系统就是中央处理器+主存储器+IO设备，这与群集性能规划是一一对应的。
③理解硬件天性
一个服务如果依赖硬盘，那这个服务就不适合扛性能压力。个别队列和分布式存储在意硬盘的性能力，但都是应用了顺序读写内容，且不介意磁盘空间浪费。顺应硬件天性，别让硬盘负载性能，别让持久依赖内存，别让网线保持稳定。
④数据的产生和消失
计算机的数据来源于输入设备和其他数据源导入，我们自定义原始数据的转化规则，所以我们如果想便捷轻巧安全可靠的获取数据，就需要选好数据源，保障好传输路径，定义好数据变换规则。我们需要在一个数据生命周期内，做好数据的容错校验、关联复原、冷热备份和安全删除来防止数据全部或部分凭空消失，我们需要自己在业务规划的实施过程中，摸索群集内有哪些角色和依赖关系。
⑤各环节都不可盲信
没有可靠的组件，我们需要自己在其中做好权衡。例如：业务应用不可靠，如果该应用能快速重建也不阻塞其他应用，月级偶发的内存泄漏和意外崩溃都是可以接受的。监控和备份是运维的职责，确认目的正确性，不要一直执着于备份数据。可以将单点硬件和系统、服务绑在一起做可靠性设计等等。
参考：原文章