【細品架構11/100】架構由術至道的轉變（2）

上一篇文章《架構由術至道的轉變（1）》已經從「人」、「組織」、「社會」三個方面講述了架構的起源，爲何會產生架構，產生架構的動力條件，並分析瞭如何能夠更好的作好架構，好比：概念認知、問題識別、架構切分，這些都是作好架構最核心、最實用的思惟手段，相信真正理解了這些道的含義，再到軟件行業進行架構實踐，會更加的遊刃有餘。

其實軟件行業也是社會的一部分，社會是由人組成的，天然架構最終是解決人的問題。有人的地方，便有了江湖，林子大了啥鳥都有，江湖中也便起了紛爭，其實歸根結底仍是人對本身利益最大化的訴求。不過在此強調下，人對利益最大化的訴求，不是產生架構的必要條件，產生架構必要條件可查看《架構由術至道的轉變（1）》。

好了，那就讓咱們來看下，在軟件行業中，架構又是爲什麼產生，又是解決人的什麼問題，最後再討論下，軟件行業的架構是如何作的。

1.  

首先，咱們要確認什麼是軟件

軟件的歷史，實際上能夠說是用機器模擬人的歷史。無論你們（包括在這個歷史過程當中的參與者）有沒有意識到，咱們都有意無心的在計算機上模仿人類的行爲。

人們愈來愈願意把原來只有人才能作的事情，交給計算機來作。結果就致使軟件愈來愈豐富，可以作的事情也愈來愈多，成本也愈來愈低。能夠這麼說，成本是咱們爲何採用軟件的主要動力，能夠節省大量的人員培訓，減小僱員的數目。隨着互聯網的發展，人類社會也開始軟件化了。

有了軟件以後，實際上，咱們是把咱們平常生活中所作的事情，包括咱們本身本人都一塊兒虛擬化到了計算機中。而人則演化成了，經過計算機的輸入輸出設備，控制計算機中的本身，來完成平常的工做，以及與其餘人的溝通。也就是說，軟件一直以來的動力，始終都是來模擬人和這個社會的。

無論如何發展，模擬人的全部行爲都是一個大的趨勢。也就是說，軟件的主要目的，仍是把人類的生活模擬化，提供更低成本，高效率的新的生活。從這個角度來看，軟件主要依賴的仍是人類的生活知識。軟件更多的是扮演一個cost center，這也是爲何會出現不少的軟件代工。

軟件架構爲什麼出現

軟件工程師是實現這個模擬過程的關鍵人物，他必須先理解人是怎麼在平常生活中完成工做的，纔可以很好的把這些工做在計算機中模擬出來。但是軟件工程師須要學習大量的計算機語言和計算機知識，還須要學習各行各業的專業知識。軟件工程師自己的培養就比較難，同時行業知識也要靠時間的積累，這樣就遠遠超出了軟件工程師的能力了。因此軟件開發就開始有分工了，行業知識和業務的識別，會交給BA，系統的設計會交給架構師，設計的實現交給架構師，實現的檢驗交給測試，還有不少其餘角色的配合。爲了組織這些角色的工做，還有項目經理。這就把原來一我的的連續工做，拆分紅了不一樣角色的人的連續配合，演化成了不一樣的軟件開發的模式。而後慢慢演變出專門爲別人開發軟件的軟件公司。

一開始是懵懵懂懂的去寫軟件，後來慢慢的就有意識的去切分，演變成了不一樣的架構。這個背後的動力也是同樣的，就是提高參與的人的利益，下降成本。導火索也是軟件工程師的任務過重，咱們須要把不少工做拆分出來。拆分的原則也是同樣的，如何讓權責一致。一樣，這個拆分也是須要組織架構的調整，來保證架構的落地。

以上經過簡單的描述計算機和軟件的發展歷史，闡明軟件的本質，其實就是經過把人類的平常工做生活虛擬化，減小成本，提高單我的員的生產力，提高人類本身的利益。軟件工程師的職責在這個浪潮中，不堪重負，天然而然就分拆爲不一樣的角色，造成了一個獨特的架構體系。這一切的背後，仍然是爲了提高人類本身的利益，解決人類本身的問題。

1.  

而後，確認軟件架構解決的核心問題

如前所述，軟件實際上就是把現實生活模擬到計算機中，而且軟件是須要在計算機的硬件中運行起來的。在這個過程當中，要作到這一點須要解決兩個問題：

1. 業務問題

   具體的現實生活狀態下，沒有軟件的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運做的？

2. 計算機問題

   （1）如何把現實生活用軟件來模擬？

   （2）模擬出來的軟件，須要哪些硬件設施纔可以知足要求？ 而且當訪問量愈來愈大的時候，軟件可否支持硬件慢慢長大，性能線性擴展？

   （3）由於硬件是可能會失效的，軟件如何在硬件失效的狀況下，仍然可以保證可用性，讓用戶可以不中斷的訪問軟件提供的服務？

   （4）怎麼收集軟件產生的數據，爲下一階段的工做提供依據？

1.  

而後，明確上面兩個核心問題主體

1. 業務owner的問題，須要提高業務的效率，下降業務的成本，這是動機，因此通常軟件開發的出發點就在這裏。
2. 軟件工程師的問題，要解決業務owner把業務虛擬化的問題，而且要解決軟件開發和運營的生命週期的問題。

1.  

而後，明確分解上面兩個核心問題

1. 業務問題的本質，是業務所服務的對象的利益問題，明白了這個，就很容易搞清業務的概念和組織方式。再次強調一下，有了軟件，能夠下降業務的成本，沒有軟件的狀況下，業務是同樣跑的。若是隻是爲了跟風要用軟件，說不定反而提升了成本，這個是採用軟件以前首先要先搞清楚的。咱們常常說軟件和技術是業務的enabler，實際就是把原來成本很高的降到到了很低的程度而已，並非有了什麼新的業務。另外軟件也不是下降業務成本的惟一方式。

2. 爲了可以讓軟件很好的跑起來，軟件工程師必須理解業務所服務的對象，他們的利益所在，即業務問題。業務面對這些問題是如何分拆解決的？ 涉及到了哪些概念？ 這些概念分別解決了哪些哪些問題？咱們不能本身按照本身的理解，用本身的一套概念體系來表述。若是這麼作的話，會致使兩個問題：

   業務沒法和咱們交流，由於他們沒法明白咱們所本身建立的概念，因此他們沒法確認咱們的理解是否正確。

   咱們所表述的東西，並無在實際生活中實踐過，咱們也不知道這些概念是否可以解決業務的問題。

3. 軟件工程師還必需要考慮，用什麼樣的硬件把軟件跑起來，怎樣跑得好，跑得快，而且能夠隨着業務的流量逐漸的長大？

1.  

分析解決分解後的問題

對於2，在有限的時間下，軟件工程師毫無疑問沒法一我的去完成這麼多事情，那麼咱們須要把所作的事情列出來，進行分析：

1. 虛擬化業務須要完成這些事情：

   1. 學習業務知識，認識業務所涉及的stakeholders的核心利益訴求，以及業務是如何分拆知足這些利益訴求，並經過怎樣的組織架構完成整個組織的核心利益的，以及業務運做的流程，涉及到哪些概念，有哪些權利和責任等。
   2. 經過對業務知識的學習，針對這些概念所對應的權利和責任以及組織架構，對業務進行建模，把並把建模的結果用編程語言實現。這是業務的模型，一般是現實生活中利益鬥爭的結果，是很是穩定的。
   3. 學習業務所參與的stakeholder是如何和業務打交道，並完成每一個人的權利和義務的，並經過編程語言，結合業務模型實現這些打交道的溝統統道。這部分是變化最頻繁的，屬於組合關係。明白了這一點，對後續的實現很是有幫助。
   4. 如何把業務運行的結果，持久化，並經過合適的手段把持久化後的數據，在合適的時間合適的地點加載出來。這部分和基礎設施有關，變化可能也會比較頻繁。

2. 代碼如何運營，須要完成這些事情：

   1. 須要多少硬件設備來知足訪問的需求？
   2. 代碼要分紅多少個組件部署到哪些硬件設備上？
   3. 這些代碼如何經過硬件設備互相鏈接在一塊兒？
   4. 當業務流量增大到超過一臺機器的容量時，軟件可否支持經過部署到新增機器上的方式，擴大對業務的支撐？
   5. 當某臺或某些硬件設備失效時，軟件是否仍然可以不影響用戶的訪問。
   6. 軟件運行產生的數據，可否支持提取出來並加以分析，爲下一輪的業務決策提供依據。

3. 若是分紅不一樣的角色來完成這些事情，就須要一個組織架構來組織代碼的編寫和運營，須要作哪些事情：

   1. 完成一和二所列的這些事情，須要哪些角色參與？
   2. 這些事情基本都須要順序的發生，如何保證信息在不一樣角色的傳遞過程當中不會有損失？ 或者說即便有損失，也能快速糾正？
   3. 這些角色之間是如何協調，才能共同完成虛擬化業務的需求？

1.  

最終，生成哪些架構

若是業務足夠簡單，用戶流量夠小，時間要求也不急迫，那麼一我的，一臺機器就夠了，這個時候通常不會去討論架構的問題。當訪問的流量愈來愈大，機器就會愈來愈多，代碼的部署單元就會拆分的愈來愈多。

一樣就會須要愈來愈多的人來完成拆分出來的愈來愈多的部署單元，甚至同一個部署單元也須要分拆爲多人合做完成。可是咱們須要注意到一點，整個的概念體系，或者說業務的建模不會有任何的變化，仍是完成一樣的這些事情。惟一的區別就是量愈來愈大，超過了單我的和單個機器的容量，不斷地增加。這樣就會致使如下的架構：

1. 當流量愈來愈大，咱們就會發現，軟件所部署的機器就會開始按照樹狀的結構開始分拆，就會造成硬件的部署架構。這就是爲何會造成部署的分層。
2. 爲了把業務在軟件中實現並落地，須要前端人員、業務代碼人員、存儲層等不一樣技巧的人同時工做，須要切分紅代碼的架構。這就是爲何會造成代碼的分層，造成代碼的架構。固然，當這些角色由一我的來完成的時候，不必定會有代碼架構，每每會比較亂。
3. 當參與的人員愈來愈多，就會造成開發體系的組織架構。由於代碼開發的過程是一個連續的過程，會用流程來把不一樣的角色串聯起來，這就是軟件工程。
4. 爲了完成業務的工做，須要識別出來業務架構和支撐業務的組織架構，以及業務運做的流程。這是被虛擬化的業務架構和組織架構，也須要體如今代碼中，保持和現實生活中一致。

1.  

再談，何爲軟件架構

這就是軟件比較複雜的地方，涉及到軟件自己的業務體系，和所虛擬的業務體系。根據以上的分析，所生成的架構，究竟那些算是軟件架構呢？

1. 軟件由於流量增大而分拆成不一樣的運行單元，在不一樣的機器上部署所造成的架構，屬於軟件架構。【部署架構】
2. 每一個運行單元爲了讓不一樣角色的人，好比前端，業務，數據存儲等可以並行工做，所分紅的代碼架構，也屬於軟件架構。【代碼架構】

因此當咱們說軟件架構的時候，咱們必定要講清楚，究竟說的是部署的架構，仍是代碼的架構。軟件架構的落地，須要軟件的組織架構和流程來保障，離開了這個，軟件架構是一句空話。

另外不少人講，架構是進化出來的，但其實架構是設計出來的，架構的好壞體現於在進化過程當中支撐業務高效運轉的生命週期。

架構實際是爲了在量不斷的增大，超過了單臺服務器的容量，逐漸的分拆，同時致使超過單我的員的能力，工做人員不斷的增多，工做內容不斷的分拆的狀況下，仍然可以良好地支撐業務流程高效運轉。這自己就是架構的意義所在。無論怎麼分拆，所達到的目標沒有任何變化，就是完成業務在計算機中的虛擬化。

做者：猿碼道 連接：https://juejin.im/post/5b3710d5e51d455f7762cd28 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。