架構漫談(六) 軟體架構到底是要解決什麼問題?

2021-09-07 07:07:27 字數 3352 閱讀 7157

前一篇文章簡述了什麼是軟體。那麼什麼是軟體架構呢?按照慣例,我們來看看是什麼問題,是誰的問題。

要解決誰的問題?

如前所述,軟體實際上就是把現實生活模擬到計算機中,並且軟體是需要在計算機的硬體中執行起來的。要做到這一點需要解決兩個問題:

一、業務問題

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

二、計算機問題

如何把現實生活用軟體來模擬?

模擬出來的軟體,需要哪些硬體設施才能夠滿足要求? 並且當訪問量越來越大的時候,軟體能否支援硬體慢慢長大,效能線性擴充套件?

因為硬體是可能會失效的,軟體如何在硬體失效的情況下,仍然能夠保證可用性,讓使用者能夠不中斷的訪問軟體提供的服務?

怎麼收集軟體產生的資料,為下一階段的工作提供依據?

分別是誰的問題呢?

業務的owner需要提公升業務的效率,降低業務的成本,這是動機。這個實際上就是業務的問題,所以一般軟體開發的出發點就在這裡。

是軟體工程師的問題,要解決業務owner把業務虛擬化的問題,並且要解決軟體開發和運營的生命週期的問題。

分別有什麼問題?

業務問題的本質,是業務所服務的物件的利益問題,明白了這個,就很容易搞清業務的概念和組織方式。再次強調一下,有了軟體,可以降低業務的成本,沒有軟體的情況下,業務是一樣跑的。如果只是為了跟風要用軟體,說不定反而提高了成本,這個是採用軟體之前首先要先搞清楚的。我們經常說軟體和技術是業務的enabler,實際就是把原來成本很高的降到到了很低的程度而已,並不是有了什麼新的業務。另外,軟體也不是降低業務成本的唯一方式。

為了能夠讓軟體很好的跑起來,軟體工程師必須理解業務所服務的物件,他們的利益所在,即業務問題。業務面對這些問題是如何分拆解決的? 涉及到了哪些概念? 這些概念分別解決了哪些哪些問題? 我們不能自己按照自己的理解,用自己的一套概念體系來表述。如果這麼做的話,會導致兩個問題:

1)業務無法和我們交流,因為他們無法明白我們所自己建立的概念,所以他們無法確認我們的理解是否正確。

2)我們所表述的東西,並沒有在實際生活中實踐過,我們也不知道這些概念是否能夠解決業務的問題。

軟體工程師還必須要考慮,用什麼樣的硬體把軟體跑起來,怎樣跑得好,跑得快,並且可以隨著業務的流量逐漸的長大?

分析問題

對於2,在有限的時間下,軟體工程師毫無疑問無法乙個人去完成這麼多事情,那麼我們需要把所做的事情列出來,進行分析。

一、虛擬化業務需要完成這些事情:

學習業務知識,認識業務所涉及的stakeholders的核心利益述求,以及業務是如何分拆滿足這些利益訴求,並通過怎樣的組織架構完成整個組織的核心利益的,以及業務運作的流程,涉及到哪些概念,有哪些權利和責任等。

通過對業務知識的學習,針對這些概念所對應的權利和責任以及組織架構,對業務進行建模,並把建模的結果用程式語言實現。這是業務的模型,通常是現實生活中利益鬥爭的結果,是非常穩定的。

學習業務所參與的stakeholder是如何和業務打交道,並完成每個人的權利和義務的,並通過程式語言,結合業務模型實現這些打交道的溝通通道。這部分是變化最頻繁的,屬於組合關係。明白了這一點,對後續的實現非常有幫助。

如何把業務執行的結果持久化,並通過合適的手段把持久化後的資料,在合適的時間合適的地點載入出來。這部分和基礎設施有關,變化可能也會比較頻繁。

二、**如何運營,需要完成這些事情:

需要多少硬體裝置來滿足訪問的需求?

**要分成多少個元件部署到哪些硬體裝置上?

這些**如何通過硬體裝置互相連線在一起?

當業務流量增大到超過一台機器的容量時,軟體能否支援通過部署到新增機器上的方式,擴大對業務的支撐?

當某台或某些硬體裝置失效時,軟體是否仍然能夠不影響使用者的訪問。

軟體執行產生的資料,能否支援提取出來並加以分析,為下一輪的業務決策提供依據。

三、如果分成不同的角色來完成這些事情,就需要乙個組織架構來組織**的編寫和運營,需要做哪些事情:

完成一和二所列的這些事情,需要哪些角色參與?

這些事情基本都需要順序的發生,如何保證資訊在不同角色的傳遞過程中不會有損失? 或者說即使有損失,也能快速糾正?

這些角色之間是如何協調,才能共同完成虛擬化業務的需求?

會生成哪些架構

如果業務足夠簡單,使用者流量夠小,時間要求也不急迫,那麼乙個人,一台機器就夠了,這個時候一般不會去討論架構的問題。當訪問的流量越來越大,機器就會越來越多,**的部署單元就會拆分的越來越多。

同樣就會需要越來越多的人來完成拆分出來的越來越多的部署單元,甚至同乙個部署單元也需要分拆為多人合作完成。但是我們需要注意到一點,整個的概念體系,或者說業務的建模不會有任何的變化,還是完成同樣的這些事情。唯一的區別就是量越來越大,超過了單個人和單個機器的容量,不斷地增長。這樣就會導致以下的架構:

當流量越來越大,我們就會發現,軟體所部屬的機器就會開始按照樹狀的結構開始分拆,就會形成硬體的部屬架構。這就是為什麼會形成部署的分層。

為了把業務在軟體中實現並落地,需要前端人員、業務**人員、儲存層等不同技巧的人同時工作,需要切分成**的架構。這就是為什麼會形成**的分層,形成**的架構。當然,當這些角色由乙個人來完成的時候,不一定會有**架構,往往會比較亂。

當參與的人員越來越多,就會形成開發體系的組織架構。因為**開發的過程是乙個連續的過程,會用流程來把不同的角色串聯起來,這就是軟體工程。

為了完成業務的工作,需要識別出來業務架構和支撐業務的組織架構,以及業務運作的流程。這是被虛擬化的業務架構和組織架構,也需要體現在**中,保持和現實生活中一致。

什麼是軟體架構

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

軟體因為流量增大而分拆成不同的執行單元,在不同的機器上部署所形成的架構,屬於軟體架構。

每個執行單元為了讓不同角色的人,比如前端,業務,資料儲存等能夠並行工作,所分成的**架構,也屬於軟體架構。

所以當我們說軟體架構的時候,我們一定要講清楚,究竟說的是部署的架構,還是**的架構。軟體架構的落地,需要軟體的組織架構和流程來保障,離開了這個,軟體架構是一句空話。

另外很多人講,架構是進化出來的。架構實際上是在量不斷的增大,超過了單台伺服器的容量,逐漸的分拆,同時導致超過單個人員的能力,工作人員不斷的增多,工作內容不斷的分拆形成的。這本身就是架構的意義所在。不管怎麼分拆,所達到的目標沒有任何變化,就是完成業務在計算機中的虛擬化。

架構漫談(六) 軟體架構到底是要解決什麼問題?

前一篇文章簡述了什麼是軟體。那麼什麼是軟體架構呢?按照慣例,我們來看看是什麼問題,是誰的問題。要解決誰的問題?如前所述,軟體實際上就是把現實生活模擬到計算機中,並且軟體是需要在計算機的硬體中執行起來的。要做到這一點需要解決兩個問題 一 業務問題 具體的現實生活狀態下,沒有軟體的時候,所解決的問題的主...

架構漫談 軟體架構師

通過對架構漫談九篇部落格的閱讀,我了解到了軟體架構以及軟體架構師的工作狀況等內容 對於架構,我的理解是,在乙個系統中,存在乙個系統中多個角色共有的問題,為了更快更好地解決問題,將問題進行拆分,交由不同的角色來完成,並在各角色中建立溝通機制,進行有機的聯絡,總成乙個整體,完成目標系統的工作。了解到架構...

架構 到底是個什麼東西 轉

舉個例子吧。你要在螢幕上列印 hello wrold.ok 你寫下 prtinf hello world.然後,你有希望能夠寫道檔案中。於是改為 if 螢幕 else 檔案 再然後,你有希望能夠寫到印表機。if 螢幕 else 檔案 else 印表機 於是你感覺有點煩 想辦法 如何不改動程式或少改動...