万物都有其本质，也只有了解了事物的本质之后，才不至于出现在事物稍作改变时就难以应对的情况，作为软件工程专业的学生，我们应该对IT架构的本质有一定的了解。“老僧三十年前未参禅时，见山是山，见水是水。及至后来，亲见知识，有个入出，见山不是山，见水不是水。而今得个休歇处，依前见山只是山，见水只是水。”这是参禅的三重境界，但同样适用于IT技术圈，初出茅庐的新手觉得每个产品都是有一定的技术难度的，他们学习着一门又一门的新语言，追逐着最强的IDE；有一定阅历与经验的前辈们深知各语言的优点与劣势，最好的语言也时常会有人对其发出嘲讽；然而当一切都沉淀下来以后，我们会明白，搞IT其实不过就是一份延续思想以及翻译语言的工作，例如技术架构师，这是一份古朴甚至有些无趣的工作。
架构技术像机器人哄小孩一样简单，各角色分工明确方便快速实现业务，但是也给架构优化埋下了大坑，底层的盲目支撑是巨大资源浪费，平级调度协作也没任何弹性，A系统会等B系统等到死锁就是架构悲剧。搞架构设计最重要的就是砍需求，将上层应用的需求优化删减，让同级的业务能容错，抓住核心诉求，不该要的东西通通不要。
作者对架构师的工作做出了五条基于核心道理的总结：1. 需求优化最重要：少查少写少依赖；2.群集设计通用规则：前端复制后端拆，实时改异步，三组件互换；3. 理解硬件天性：角色选型时要看硬件的天然特性；4. 数据的产生和消失：数据不会凭空产生，但会凭空消失；5. 各环节都不可盲信：容灾设计中都尽人事和听天命。
前端是管道是逻辑，而后端是状态是数据，所以前端复制后端拆。在群集性能规划中，网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的，架构师要完成补不足而损有余的选型。每个新选型都会带来细节上的万千变化，但每种变化都是符合自然规律有章可循的。例如，一个经典微机系统就是中央处理器+主存储器+IO设备，而这几个概念居然是和群集性能规划一一对应的。
架构层软件技术已经足够成熟，所谓技术选型不如说是适应场景；在做具体角色选型时，最深度也最易忽视的原则是顺应硬件天性。作者的精神导师说过，如果一个服务依赖硬盘，那这个服务就不适合扛性能压力。天性不可逆转，所谓理解硬件的天然特性，就是别让硬盘扛性能，别让内存保持久，别让网线扛稳定。
写代码时会遇见很多难以理解的问题，你可能不明白这个错是怎么出现的，也不知道那个错怎么下一秒忽然就没了，但我们需要知道的是，数据不会凭空产生，但有可能会凭空消失。计算机或者自输入设备获取数据，或者自其他数据源导入数据，而且原始数据的转化规则也要人类来定义。我们要便捷轻巧安全可靠的获取数据，就要选好数据源，保障好传输路径，定义好数据变换规则。在一个数据生命周期内，为了防止数据全部或部分凭空消失，数据的容错校验、关联复原、冷热备份和安全删除都要考虑到位。
架构师的核心技能包括画好访问逻辑和数据流量图，因为问题现状描述清楚了，问题就解决了一多半了。一个好的业务访问逻辑图，其信息量大到包罗访问过程的所有元素，同时也要详略得当高亮关键点。在生僻业务的规划实施过程中，没人告诉架构师该有哪些服务，他们只能靠摸透一个又一个访问逻辑图和数据生命周期，来摸索群集内有哪些角色和依赖关系。
要知道整个IT系统中就没有可靠的组件，架构师既不能盲目信任撞大运，又不能无限冗余吓唬自己，而是在尽人事和听天命之间做好权衡，不出故障的人是不存在的，不出错的标准难以达到。如果出了大范围的故障，只要员工没有恶意破坏，那就是群集健壮性设计不到位，是技术总监和架构师的锅，而非操作工。
作者说过庖丁可以解牛也可以杀猪，做架构的，明白了架构之道，以其作为思想支撑，即使面对的是全新业务类型，也能做到面不改色游刃有余。
