- 需求优化最重要
一个IT系统是多角色多模块分层分级的，像OSI模型上层应用简单依赖下层支撑，SOA设计中同级角色也只看对方的接口。
各角色分工明确方便快速实现业务，但是给架构优化也埋下大坑，底层的盲目支撑是巨大资源浪费，平级调度协作也没任何弹性。前端一个小逻辑需求会导致后端大规模联动，不同服务也没权限理解对方的内存数据，各个角色的工程师都只看自己的工作范围，这是正常又无奈的现状。
我们要搞架构设计最重要的就是砍需求，将上层应用的需求优化删减，让同级的业务能容错。上层需求优化，即前端对后端少输入少查询多容错，而同级容错可以看做应用间的需求优化，比如两个服务可以幂等重试就是好解耦，而A系统会等B系统等到死锁就是架构悲剧。
- 群集设计通用规则
前端复制后端拆，实时改异步，IO-算力-空间可互换——要做架构就要上群集，而群集设计调优翻来覆去就是这三板斧：
前端是管道是逻辑，而后端是状态是数据，所以前端复制后端拆。前端服务器压力大了就多做水平复制扩容，在网站类应用上，无状态-会话保持-弹性伸缩等技术应用纯熟。后端要群集化就是多做业务拆分，常见的就是数据库拆库拆表拆键值，服务拆的越散微操作就越爽，但全局操作开销更大更难控制。
实时改异步是我学的最后一门IT技术，绝大部分“实时操作”都不是业务需求，而是某应用无法看到后端和Peer状态，默认就要实时处理结果了。CS模式的实时操作会给支撑服务带来巨大压力，Peer合作的实时操作可能会让数据申请方等一宿。架构师将一个无脑大事务拆分成多个小事务，这就是异步架构，但拆分事务就跟拆分数据表一样，拆散的小事务需要更高业务层级上做全局事务保障。
在群集性能规划中，网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的，架构师要完成补不足而损有余的选型。比如数据压缩技术就是用算力资源来置换IO和空间，缓存技术是用空间和IO来缓解算力压力，每个新选型都会带来细节上的万千变化，但每种变化都是符合自然规律有章可循的。 一个经典微机系统就是中央处理器+主存储器+IO设备，这几个概念居然和群集性能规划是一一对应。
- 理解硬件天性
别让硬盘扛性能，别让内存保持久，别让网线扛稳定。
架构层软件技术已经足够成熟，所谓技术选型不如说是适应场景；在做具体角色选型时，最深度也最易忽视的原则是顺应硬件天性。
我的精神导师说过，如果一个服务依赖硬盘，那这个服务就不适合扛性能压力。我经常将读写引到/dev/shm；SSD盘让很多细节调优聊胜于无，还让Fat32枯木逢春；个别队列和分布式存储在意硬盘的性能力，但都是应用了顺序读写内容，且不介意磁盘空间浪费。
别让内存扛持久和别让网线扛稳定，听起来很简单，但新手程序员总会犯低级错误，而犯错早晚要还技术债。常规例子就是看新手程序是否有捕获各种异常的习惯，举个争议性例子，某些云服务设计者尝试给一个进程映射和绑定持久文件系统，请问一段内存如何绑定一块硬盘？
- 数据的产生和消失
数据不会凭空产生，计算机或者自输入设备获取数据，或者自其他数据源导入数据，而且原始数据的转化规则也要人类来定义。我们要便捷轻巧安全可靠的获取数据，就要选好数据源，保障好传输路径，定义好数据变换规则。
在一个数据生命周期内，为了防止数据全部或部分凭空消失，数据的容错校验、关联复原、冷热备份和安全删除都要考虑到位。
在生僻业务的规划实施过程中，没人告诉我们该有哪些服务，我们只能靠摸透一个又一个访问逻辑图和数据生命周期，来摸索群集内有哪些角色和依赖关系。
- 各环节都要保持谨慎
整个IT系统中就没有可靠的组件，架构师既不能盲目信任撞大运，又不能无限冗余吓唬自己，而是在尽人事和听天命之间做好权衡。
-----------转载自微信公众号：云时代架构