架构阅读笔记5
阅读使人明智，阅读他人的经验使自己明智。架构设计最重要的就是砍需求，将上层应用的需求优化删减，让同级的业务能容错。上层需求优化，即前端对后端少输入少查询多容错，而同级容错可以看做应用间的需求优化，比如两个服务可以幂等重试就是好解耦，而A系统会等B系统等到死锁就是架构悲剧。即抓住核心诉求，不该要的东西都不要。例如，对于一个完美的播放器，它可以自助容错选择CDN，可以主动预缓存下一分钟的点播内容，可以完成私有解密编码工作，可以和广告系统解耦独立加载，可以在卡顿时更换线路和存储日志，广告日志和卡顿日志都低速适时后台上传。对于查询，系统越慢用户就重复点查询按钮，而并行查询越多后台速度越慢，这样就进入了恶性循环。这种环境要搞架构优化，要理解核心需求，要理解自然人并不要求实时数据，ERP客户端限制每15秒才能点一次查询按钮，在Web接入层限制每个Session每分钟只能查询一次，还可在数据库链接类库上做一层控制策略，这样可以提高速度。
前端复制后端拆，实时改异步，IO-算力-空间可互换——要做架构就要上群集，而群集设计调优翻来覆去就是这三板斧：前端是管道是逻辑，而后端是状态是数据，所以前端复制后端拆。前端服务器压力大了就多做水平复制扩容，在网站类应用上，无状态-会话保持-弹性伸缩等技术应用纯熟。后端要群集化就是多做业务拆分，常见的就是数据库拆库拆表拆键值，服务拆的越散微操作就越爽，但全局操作开销更大更难控制。在群集性能规划中，网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的，架构师要完成补不足而损有余的选型。
理解硬件天性，技术选型适应场景。不同角色适应不同的硬件，将硬件的功能做到极致。
数据不会凭空产生，计算机或者自输入设备获取数据，或者自其他数据源导入数据，而且原始数据的转化规则也要人类来定义。在一个数据生命周期内，为了防止数据全部或部分凭空消失，数据的容错校验、关联复原、冷热备份和安全删除都要考虑到位。摸透一个又一个访问逻辑图和数据生命周期，来摸索群集内有哪些角色和依赖关系。架构师的核心技能包括画好访问逻辑和数据流量图，因为问题现状描述清楚了，问题就解决了一多半了。
在架构系统时，要做好尽人事和听天命的权衡，比如业务应用、支撑性服务、操作系统故障、网络、硬件不稳定、人力误操作、监控和备份。时刻做好风险的防范，做好风险的应对。
不同业务系统的架构不同，“道”却相同，“术”则根据日常学习与积累，积累经验。