架構漫談是由資深架構師王概凱Kevin執筆的系列專欄，專欄将會以Kevin的架構經驗為基礎，逐漸讨論什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程式等問題。
本文是漫談架構專欄的第六篇，作者Kevin繼續沿着前幾篇文章的思路，探讨了軟體架構為什麼要有軟體架構，進而再去解釋什麼是軟體架構。這和最近網上瘋傳的黃金圓環（Why-How-What）思路非常貼合。
前一篇文章簡述了什麼是軟體。那麼什麼是軟體架構呢？按照慣例，我們來看看是什麼問題，是誰的問題。
相關廠商内容
相關贊助商
如前所述，軟體實際上就是把現實生活模拟到計算機中，并且軟體是需要在計算機的硬體中運作起來的。要做到這一點需要解決兩個問題：
具體的現實生活狀态下，沒有軟體的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運作的？
如何把現實生活用軟體來模拟？
模拟出來的軟體，需要哪些硬體設施才能夠滿足要求？ 并且當通路量越來越大的時候，軟體能否支援硬體慢慢長大，性能線性擴充？
因為硬體是可能會失效的，軟體如何在硬體失效的情況下，仍然能夠保證可用性，讓使用者能夠不中斷的通路軟體提供的服務？
怎麼收集軟體産生的資料，為下一階段的工作提供依據？
業務的owner需要提升業務的效率，降低業務的成本，這是動機。這個實際上就是業務的問題，是以一般軟體開發的出發點就在這裡。
是軟體工程師的問題，要解決業務owner把業務虛拟化的問題，并且要解決軟體開發和營運的生命周期的問題。
(點選放大圖像)
業務問題的本質，是業務所服務的對象的利益問題，明白了這個，就很容易搞清業務的概念群組織方式。再次強調一下，有了軟體，可以降低業務的成本，沒有軟體的情況下，業務是一樣跑的。如果隻是為了跟風要用軟體，說不定反而提高了成本，這個是采用軟體之前首先要先搞清楚的。我們經常說軟體和技術是業務的enabler，實際就是把原來成本很高的降到到了很低的程度而已，并不是有了什麼新的業務。另外軟體也不是降低業務成本的唯一方式。
為了能夠讓軟體很好的跑起來，軟體工程師必須了解業務所服務的對象，他們的利益所在，即業務問題。業務面對這些問題是如何分拆解決的？ 涉及到了哪些概念？ 這些概念分别解決了哪些哪些問題？ 我們不能自己按照自己的了解，用自己的一套概念體系來表述。如果這麼做的話，會導緻兩個問題：
業務無法和我們交流，因為他們無法明白我們所自己建立的概念，是以他們無法确認我們的了解是否正确。
我們所表述的東西，并沒有在實際生活中實踐過，我們也不知道這些概念是否能夠解決業務的問題。
軟體工程師還必須要考慮，用什麼樣的硬體把軟體跑起來，怎樣跑得好，跑得快，并且可以随着業務的流量逐漸的長大？
對于2，在有限的時間下，軟體工程師毫無疑問無法一個人去完成這麼多事情，那麼我們需要把所做的事情列出來，進行分析。
一、虛拟化業務需要完成這些事情：
學習業務知識，認識業務所涉及的stakeholders的核心利益述求，以及業務是如何分拆滿足這些利益述求，并通過怎樣的組織架構完成整個組織的核心利益的，以及業務運作的流程，涉及到哪些概念，有哪些權利和責任等。
通過對業務知識的學習，針對這些概念所對應的權利和責任以及組織架構，對業務進行模組化，把并把模組化的結果用程式設計語言實作。這是業務的模型，通常是現實生活中利益鬥争的結果，是非常穩定的。
學習業務所參與的stakeholder是如何和業務打交道，并完成每個人的權利和義務的，并通過程式設計語言，結合業務模型實作這些打交道的溝通通道。這部分是變化最頻繁的，屬于組合關系。明白了這一點，對後續的實作非常有幫助。
如何把業務運作的結果，持久化，并通過合适的手段把持久化後的資料，在合适的時間合适的地點加載出來。這部分和基礎設施有關，變化可能也會比較頻繁。
二、代碼如何營運，需要完成這些事情：
需要多少硬體裝置來滿足通路的需求？
代碼要分成多少個元件部署到哪些硬體裝置上？
這些代碼如何通過硬體裝置互相連接配接在一起？
當業務流量增大到超過一台機器的容量時，軟體能否支援通過部署到新增機器上的方式，擴大對業務的支撐？
當某台或某些硬體裝置失效時，軟體是否仍然能夠不影響使用者的通路。
軟體運作産生的資料，能否支援提取出來并加以分析，為下一輪的業務決策提供依據。
三、如果分成不同的角色來完成這些事情，就需要一個組織架構來組織代碼的編寫和營運，需要做哪些事情：
完成一和二所列的這些事情，需要哪些角色參與？
這些事情基本都需要順序的發生，如何保證資訊在不同角色的傳遞過程中不會有損失？ 或者說即使有損失，也能快速糾正？
這些角色之間是如何協調，才能共同完成虛拟化業務的需求？
如果業務足夠簡單，使用者流量夠小，時間要求也不急迫，那麼一個人，一台機器就夠了，這個時候一般不會去讨論架構的問題。當通路的流量越來越大，機器就會越來越多，代碼的部署單元就會拆分的越來越多。
同樣就會需要越來越多的人來完成拆分出來的越來越多的部署單元，甚至同一個部署單元也需要分拆為多人合作完成。但是我們需要注意到一點，整個的概念體系，或者說業務的模組化不會有任何的變化，還是完成同樣的這些事情。唯一的差別就是量越來越大，超過了單個人和單個機器的容量，不斷地增長。這樣就會導緻以下的架構：
當流量越來越大，我們就會發現，軟體所部屬的機器就會開始按照樹狀的結構開始分拆，就會形成硬體的部屬架構。這就是為什麼會形成部署的分層。
為了把業務在軟體中實作并落地，需要前端人員、業務代碼人員、存儲層等不同技巧的人同時工作，需要切分成代碼的架構。這就是為什麼會形成代碼的分層，形成代碼的架構。當然，當這些角色由一個人來完成的時候，不一定會有代碼架構，往往會比較亂。
當參與的人員越來越多，就會形成開發體系的組織架構。因為代碼開發的過程是一個連續的過程，會用流程來吧不同的角色串聯起來，這就是軟體工程。
為了完成業務的工作，需要識别出來業務架構和支撐業務的組織架構，以及業務運作的流程。這是被虛拟化的業務架構群組織架構，也需要展現在代碼中，保持和現實生活中一緻。
這就是軟體比較複雜的地方，涉及到軟體本身的業務體系，和所虛拟的業務體系。根據以上的分析，所生成的架構，究竟那些算是軟體架構呢？
軟體因為流量增大而分拆成不同的運作單元，在不同的機器上部署所形成的架構，屬于軟體架構。
每個運作單元為了讓不同角色的人，比如前端，業務，資料存儲等能夠并行工作，所分成的代碼架構，也屬于軟體架構。
是以當我們說軟體架構的時候，我們一定要講清楚，究竟說的是部署的架構，還是代碼的架構。軟體架構的落地，需要軟體的組織架構和流程來保障，離開了這個，軟體架構是一句空話。
另外很多人講，架構是進化出來的。架構實際上是在量不斷的增大，超過了單台伺服器的容量，逐漸的分拆，同時導緻超過單個人員的能力，從業人員不斷的增多，工作内容不斷的分拆形成的。這本身就是架構的意義所在。不管怎麼分拆，所達到的目标沒有任何變化，就是完成業務在計算機中的虛拟化。