假设⽤Java语⾔绘制⼀个⼤型⽹站，其典型架构如图2-1所⽰。
图2-1 ⼤型⽹站的典型架构
但这张图并不能说明什么问题，因为实际的架构决策并不能在这张图上反映出来。⽐如：
· 如何拆分服务？
· 如何组织服务与服务之间的层次关系？
· 如何设计接⼜？
· 缓存数据结构与更新策略是什么样的？
· 缓存宕机后系统是否可⽤？
· 数据库如何分库分表？
· 消息队列在什么地⽅使⽤？
· 需要部署多少台Tomcat？需要部署多少台RPC服务？
……
这个问题的列表可以无限长。本书将提供⼀个系统的⽅法论，帮助读者分析和解决这⼀系列问题。
这个⽅法论，即是架构的道。具体来说，对于技术问题，主要指⾼并发、⾼可⽤和⼀致性⽅⾯；对于业务问题，主要指业务的需求分析和业务建模。这些⽅法论来⾃⼤量的业务系统实践，并在实践基础上进⾏了思考和总结。
道的东西往往会⽐较虚，可能说了半天对⽅还是不知道你说的是什么。但越是“虚”，越是“抽象”，就越有必要阐释清楚，⽽这也正是本书要试图解决的⼀个问题：把抽象⽞幻的业务建模⽅法论、晦涩难懂的分布式⼀致性理论，⽤通俗的语⾔表达出来，让读者可以从⼀个“最朴素的视⾓”去看待这些理论。
但要讲道，⾸先得讲术，因为得先有“地基”。术⽅⾯的东西⼤家⽐较容易理解，就是某种具体的语⾔、框架或中间件的使⽤技巧。术的东西⽐较具体，具有实操性，容易描述，不会陷⼊“不知所云”的局⾯。
本书不会把道上升到哲学层⾯，虽然最终所有的学科、学问被抽象到⼀定的程度往往会上升到哲学⾼度。本书会尽可能把道局限在解决“业务的技术问题”层⾯，尽可能“⾔之有物”，避免⼤⽽空洞。
在武侠⼩说中，练就⼀门顶级武功，会同时涉及两个东西：⼀是内功⼼法，⼆是外部招式。前者是道，后者是术。但凡武林中的顶级⾼⼿，⼀定具有深厚的内功。那些招式花哨但内功不深厚的⼈，在江湖上通常只能在平常⼈中耀武扬威，⼀旦跟⾼⼿过招，往往只需⼏个回合就会原形毕露。
这样⽐喻道和术的关系很容易理解。但这样说又有夸⼤内功⼼法、轻视外部招式的嫌疑，让⼈觉得内功⼼法⽐外部招式重要，导致外部招式被忽视。
在中国哲学（主要来⾃儒家）中，⼀直有⼀个核⼼思想：“知⾏合⼀”。个⼈觉得⽤这个来表达道和术的关系会更为贴切。知，是理论，是套路，是解决问题的⽅法论；⾏，是实践，是操作，⽤于解决⼀个个实际问题。先有实践，然后总结出理论，⽤理论指导新的实践，在新的实践中再总结出新的理论。如此循环往复，即是归纳和演绎循环往复的过程，也是螺旋式上升的过程。
具体到软件架构，就是道和术都不能偏废，⼀⽅⾯需要不断实践，在实践中深究原理；⼀⽅⾯要把实践的东西抽象、总结出来，形成⽅法论。但在实际中，为什么很多⼈热衷于术，⽽不是道呢？因为在短期能看到术的结果，想要看到道的效果却需要长期地修炼，必须到了⼀个顿悟的拐点，才能发出惊⼈的能量。
除了从“知”和“⾏”的⾓度去看待，还可以从“问题”和“答案”的⾓度去看待。术偏重“答案”，是⼯具，是锤⼦；道偏重“问题”，是钉⼦。可能是拿着锤⼦去找钉⼦，也可能是遇到钉⼦再去想找个锤⼦或造个锤⼦。
最后总结⼀下两者的关系，如表2-1所⽰。
表2-1 道与术的辩证关系
关注微信
