上一篇文章《架構由術至道的轉變（1）》已經從“人”、“組織”、“社會”三個方面講述了架構的起源，為什麼會產生架構，產生架構的動力條件，並分析瞭如何可以更好的做好架構，比如：概念認知、問題識別、架構切分，這些都是做好架構最核心、最實用的思維手段，相信真正理解了這些道的含義，再到軟體行業進行架構實踐，會更加的遊刃有餘。
其實軟體行業也是社會的一部分，社會是由人組成的，自然架構最終是解決人的問題。有人的地方，便有了江湖，林子大了啥鳥都有，江湖中也便起了紛爭，其實歸根結底還是人對自己利益最大化的訴求。不過在此強調下，人對利益最大化的訴求，不是產生架構的必要條件，產生架構必要條件可檢視《架構由術至道的轉變（1）》。
好了，那就讓我們來看下，在軟體行業中，架構又是為何產生，又是解決人的什麼問題，最後再討論下，軟體行業的架構是如何做的。
首先，我們要確認什麼是軟體
軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家（包括在這個歷史過程中的參與者）有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。
人們越來越願意把原來只有人才能做的事情，交給計算機來做。結果就導致軟體越來越豐富，能夠做的事情也越來越多，成本也越來越低。可以這麼說，成本是我們為什麼採用軟體的主要動力，可以節省大量的人員培訓，減少僱員的數目。隨著網際網路的發展，人類社會也開始軟體化了。
有了軟體之後，實際上，我們是把我們日常生活中所做的事情，包括我們自己本人都一起虛擬化到了計算機中。而人則演化成了，通過計算機的輸入輸出裝置，控制計算機中的自己，來完成日常的工作，以及與其他人的溝通。也就是說，軟體一直以來的動力，始終都是來模擬人和這個社會的。
不管如何發展，模擬人的所有行為都是一個大的趨勢。也就是說，軟體的主要目的，還是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟體主要依賴的還是人類的生活知識。軟體更多的是扮演一個cost center，這也是為什麼會出現很多的軟體代工。
軟體架構為何出現
軟體工程師是實現這個模擬過程的關鍵人物，他必須先理解人是怎麼在日常生活中完成工作的，才能夠很好的把這些工作在計算機中模擬出來。可是軟體工程師需要學習大量的計算機語言和計算機知識，還需要學習各行各業的專業知識。軟體工程師本身的培養就比較難，同時行業知識也要靠時間的積累，這樣就遠遠超出了軟體工程師的能力了。所以軟體開發就開始有分工了，行業知識和業務的識別，會交給BA，系統的設計會交給架構師，設計的實現交給架構師，實現的檢驗交給測試，還有很多其他角色的配合。為了組織這些角色的工作，還有專案經理。這就把原來一個人的連續工作，拆分成了不同角色的人的連續配合，演化成了不同的軟體開發的模式。然後慢慢演變出專門為別人開發軟體的軟體公司。
一開始是懵懵懂懂的去寫軟體，後來慢慢的就有意識的去切分，演變成了不同的架構。這個背後的動力也是一樣的，就是提升參與的人的利益，降低成本。導火索也是軟體工程師的任務太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權責一致。同樣，這個拆分也是需要組織架構的調整，來保證架構的落地。
以上通過簡單的描述計算機和軟體的發展歷史，闡明軟體的本質，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產力，提升人類自己的利益。軟體工程師的職責在這個浪潮中，不堪重負，自然而然就分拆為不同的角色，形成了一個獨特的架構體系。這一切的背後，仍然是為了提升人類自己的利益，解決人類自己的問題。
然後，確認軟體架構解決的核心問題
如前所述，軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中執行起來的。在這個過程中，要做到這一點需要解決兩個問題：
業務問題
具體的現實生活狀態下，沒有軟體的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運作的？
計算機問題
（1）如何把現實生活用軟體來模擬？
（2）模擬出來的軟體，需要哪些硬體設施才能夠滿足要求？ 並且當訪問量越來越大的時候，軟體能否支援硬體慢慢長大，效能線性擴充套件？
（3）因為硬體是可能會失效的，軟體如何在硬體失效的情況下，仍然能夠保證可用性，讓使用者能夠不中斷的訪問軟體提供的服務？
（4）怎麼收集軟體產生的資料，為下一階段的工作提供依據？
然後，明確上面兩個核心問題主體
- 業務owner的問題，需要提升業務的效率，降低業務的成本，這是動機，所以一般軟體開發的出發點就在這裡。
- 軟體工程師的問題，要解決業務owner把業務虛擬化的問題，並且要解決軟體開發和運營的生命週期的問題。
然後，明確分解上面兩個核心問題
-
業務問題的本質，是業務所服務的物件的利益問題，明白了這個，就很容易搞清業務的概念和組織方式。再次強調一下，有了軟體，可以降低業務的成本，沒有軟體的情況下，業務是一樣跑的。如果只是為了跟風要用軟體，說不定反而提高了成本，這個是採用軟體之前首先要先搞清楚的。我們經常說軟體和技術是業務的enabler，實際就是把原來成本很高的降到到了很低的程度而已，並不是有了什麼新的業務。另外軟體也不是降低業務成本的唯一方式。
-
為了能夠讓軟體很好的跑起來，軟體工程師必須理解業務所服務的物件，他們的利益所在，即業務問題。業務面對這些問題是如何分拆解決的？ 涉及到了哪些概念？ 這些概念分別解決了哪些哪些問題？我們不能自己按照自己的理解，用自己的一套概念體系來表述。如果這麼做的話，會導致兩個問題：
業務無法和我們交流，因為他們無法明白我們所自己建立的概念，所以他們無法確認我們的理解是否正確。
我們所表述的東西，並沒有在實際生活中實踐過，我們也不知道這些概念是否能夠解決業務的問題。
-
軟體工程師還必須要考慮，用什麼樣的硬體把軟體跑起來，怎樣跑得好，跑得快，並且可以隨著業務的流量逐漸的長大？
分析解決分解後的問題
對於2，在有限的時間下，軟體工程師毫無疑問無法一個人去完成這麼多事情，那麼我們需要把所做的事情列出來，進行分析：
-
虛擬化業務需要完成這些事情：
- 學習業務知識，認識業務所涉及的stakeholders的核心利益訴求，以及業務是如何分拆滿足這些利益訴求，並通過怎樣的組織架構完成整個組織的核心利益的，以及業務運作的流程，涉及到哪些概念，有哪些權利和責任等。
- 通過對業務知識的學習，針對這些概念所對應的權利和責任以及組織架構，對業務進行建模，把並把建模的結果用程式語言實現。這是業務的模型，通常是現實生活中利益鬥爭的結果，是非常穩定的。
- 學習業務所參與的stakeholder是如何和業務打交道，並完成每個人的權利和義務的，並通過程式語言，結合業務模型實現這些打交道的溝通通道。這部分是變化最頻繁的，屬於組合關係。明白了這一點，對後續的實現非常有幫助。
- 如何把業務執行的結果，持久化，並通過合適的手段把持久化後的資料，在合適的時間合適的地點載入出來。這部分和基礎設施有關，變化可能也會比較頻繁。
-
程式碼如何運營，需要完成這些事情：
- 需要多少硬體裝置來滿足訪問的需求？
- 程式碼要分成多少個元件部署到哪些硬體裝置上？
- 這些程式碼如何通過硬體裝置互相連線在一起？
- 當業務流量增大到超過一臺機器的容量時，軟體能否支援通過部署到新增機器上的方式，擴大對業務的支撐？
- 當某臺或某些硬體裝置失效時，軟體是否仍然能夠不影響使用者的訪問。
- 軟體執行產生的資料，能否支援提取出來並加以分析，為下一輪的業務決策提供依據。
-
如果分成不同的角色來完成這些事情，就需要一個組織架構來組織程式碼的編寫和運營，需要做哪些事情：
- 完成一和二所列的這些事情，需要哪些角色參與？
- 這些事情基本都需要順序的發生，如何保證資訊在不同角色的傳遞過程中不會有損失？ 或者說即使有損失，也能快速糾正？
- 這些角色之間是如何協調，才能共同完成虛擬化業務的需求？
最終，生成哪些架構
如果業務足夠簡單，使用者流量夠小，時間要求也不急迫，那麼一個人，一臺機器就夠了，這個時候一般不會去討論架構的問題。當訪問的流量越來越大，機器就會越來越多，程式碼的部署單元就會拆分的越來越多。
同樣就會需要越來越多的人來完成拆分出來的越來越多的部署單元，甚至同一個部署單元也需要分拆為多人合作完成。但是我們需要注意到一點，整個的概念體系，或者說業務的建模不會有任何的變化，還是完成同樣的這些事情。唯一的區別就是量越來越大，超過了單個人和單個機器的容量，不斷地增長。這樣就會導致以下的架構：
- 當流量越來越大，我們就會發現，軟體所部署的機器就會開始按照樹狀的結構開始分拆，就會形成硬體的部署架構。這就是為什麼會形成部署的分層。
- 為了把業務在軟體中實現並落地，需要前端人員、業務程式碼人員、儲存層等不同技巧的人同時工作，需要切分成程式碼的架構。這就是為什麼會形成程式碼的分層，形成程式碼的架構。當然，當這些角色由一個人來完成的時候，不一定會有程式碼架構，往往會比較亂。
- 當參與的人員越來越多，就會形成開發體系的組織架構。因為程式碼開發的過程是一個連續的過程，會用流程來把不同的角色串聯起來，這就是軟體工程。
- 為了完成業務的工作，需要識別出來業務架構和支撐業務的組織架構，以及業務運作的流程。這是被虛擬化的業務架構和組織架構，也需要體現在程式碼中，保持和現實生活中一致。
再談，何為軟體架構
這就是軟體比較複雜的地方，涉及到軟體本身的業務體系，和所虛擬的業務體系。根據以上的分析，所生成的架構，究竟那些算是軟體架構呢？
- 軟體因為流量增大而分拆成不同的執行單元，在不同的機器上部署所形成的架構，屬於軟體架構。【部署架構】
- 每個執行單元為了讓不同角色的人，比如前端，業務，資料儲存等能夠並行工作，所分成的程式碼架構，也屬於軟體架構。【程式碼架構】
所以當我們說軟體架構的時候，我們一定要講清楚，究竟說的是部署的架構，還是程式碼的架構。軟體架構的落地，需要軟體的組織架構和流程來保障，離開了這個，軟體架構是一句空話。
另外很多人講，架構是進化出來的，但其實架構是設計出來的，架構的好壞體現於在進化過程中支撐業務高效運轉的生命週期。
架構實際是為了在量不斷的增大，超過了單臺伺服器的容量，逐漸的分拆，同時導致超過單個人員的能力，工作人員不斷的增多，工作內容不斷的分拆的情況下，仍然能夠良好地支撐業務流程高效運轉。這本身就是架構的意義所在。不管怎麼分拆，所達到的目標沒有任何變化，就是完成業務在計算機中的虛擬化。