首頁 > EA > 正文

架構漫談:軟件的架構拆分之道

2018-08-10 10:11:28  來源:網絡 作者:王概凱

摘要:軟件需要拆分,這是眾所周知的。但是如何拆分,根據什么原則拆分,則眾說紛紜,各有各的道理。
關鍵詞: 企業架構 軟件架構
本文是的第十篇文章,作者將會重點談軟件拆分背后的原則和原理,對于我們每一個人來說,理解這些背后的原則,可以讓我們在復雜的情況下不再迷茫。如果我們每一個人在自己的能力范圍之內,嘗試往這個方向努力,真正的為軟件開發的環境帶來改變,這就善莫大焉了,這篇文章的目的也就達到了。
 
軟件需要拆分,這是眾所周知的。但是如何拆分,根據什么原則拆分,則眾說紛紜,各有各的道理。甚至有人認為把架構一步到位的做好是不是更好?還有很多人根據自己的經驗從技術的角度去進行主動拆分。因為從技術上講,每個人對技術的理解都不太一樣,都有自己的側重點和道理,拆的方案都是符合自己的利益的。
 
“別人”的問題能否得到很好的解決呢?是不是反而拆出來更多的問題,導致更加惡化?在實際的操作過程中我們更多看到的是:系統遇到瓶頸,被迫加班加點的進行拆分,并把這個叫做架構的演化。以下打算探討一下軟件拆分的原則和方法,可以把本篇看做的進一步細化,請大家結合起來閱讀。
 
軟件拆分的原動力
 
軟件架構拆分的原動力實際上是來源于業務本身的切分所形成的組織架構。這個似乎比較難理解,我們先從業務本身分析。業務的組織架構是怎么形成的呢? 業務組織架構的背后原動力,如架構漫談第四篇所說,是每個人的負載超限。這個負載主要是人的時間不夠,無法在一個人有限的時間內完成大量的業務,就只能把整個工作的大的生命周期,切分為小的生命周期,形成一個樹狀架構,授權給具備不同專業技能的人對各自所負責的生命周期負全責。
 
而分拆的人則成為了整個組織的領導,負責把各個子生命周期的運行結果組合為自己的產出,這樣他一個人在相同時間內的產出就放大了許多倍。比如一個公司剛開始時,CEO一個人處理所有業務。這個時候客戶比較少,問題還不大。
 
當業務逐漸上來,客戶量和業務規模逐漸上來的時候,CEO一個人就不可能做所有的事情了,自然就把他自己做的所有的事情(也就是整個公司運營的生命周期),切分為更小的生命周期,分配給不同的專業的人來運營,形成一個樹狀的架構:
 
當然,每個專業領域還可以把自己的生命周期細分解成更小的生命周期,以提升自己的生產力。但是當增長到一定程度的時候,溝通成本就成了主要的損耗,不可能無限的增長下去。所以引入軟件系統來提升生產力就順理成章了。軟件實際是扮演一個替代人的作用,把很多人做的事情,交給軟件來做。如果業務人員能夠進行軟件開發,那么這是最好的(未來應該是一個趨勢),他們自行把自己的職責自動化,就可以提升自己的生產力。但是實際情況是,軟件開發門檻還是很高,所以必須成立獨立的軟件開發團隊來服務于業務人員。
 
以上看起來好像說的是傳統企業采用軟件的過程,但實際上是想說明企業背后架構發展的邏輯,并非特指傳統企業?;ヂ摼W企業的發展也是一樣的,和傳統企業的區別在于,互聯網企業一開始就專注于采用軟件來提升生產力,業務團隊的增長往往會慢于軟件體系的增長。因為軟件強大,業務人的生產力提高的非???,不需要大量的業務人員投入,但需要大量的軟件開發投入。但是絕對不可以因為沒有經歷無軟件的純業務期,而忽視業務團隊,放棄以業務為中心。因為軟件是為人服務的,是為業務服務的,先有人,有業務,才有軟件,這個次序絕對不可以顛倒。沒有人,軟件就失去了模擬的目標,軟件就沒有價值了。
 
軟件開發團隊的拆分
 
因為需要把業務部門提出的需求用軟件來實現,自然需要建立軟件開發團隊。那么對于不同的業務團隊提出的需求,軟件開發團隊又應該如何分工組織來應對呢?我們分幾種情況來分析:
 
情況1, 多個業務團隊對應一個軟件開發團隊。
 
在這種情況下,很容易就出現軟件開發團隊中的某些人會處理多個不同業務團隊的問題,進而就很容易導致多個不同業務團隊的需求,以省力或者重用的理由,全部或者部分的整合在了同一個軟件中。這樣就會導致這些業務部門都在提需求的時候,軟件開發團隊內部之間,軟件開發團隊和業務部門之間,會產生大量的互相依賴,干擾,扯皮,也會產生大量的會議,降低整個團隊的效率。最終這些軟件之間的依賴狀況會變得錯綜復雜,軟件上線也會變成一個純靠運氣的活了。
 
情況2,一個業務團隊對應多個軟件開發團隊。
 
在這種情況下,業務團隊必須要自行對業務需求拆分,以便給到相應的開發團隊。而業務團隊一般都不具備這個能力,只能同時和多個軟件開發團隊一起開會討論,同樣會有很多的溝通,扯皮。并且這種溝通是持續的,每次調整都需要所有團隊來開會,效率非常的低下。并且初期的分工所形成的職責切分,隨著溝通的進展,會變得越來越模糊,最終也會變成和情況1類似的情況,軟件的之間的依賴狀況會變的錯綜復雜,軟件上線也變成了運氣活,要燒香求神了。
 
情況3,一個業務團隊對應一個軟件開發團隊。
 
這樣每個業務部門都有獨立的軟件開發團隊來配合。這些軟件開發團隊只對應一個業務團隊,所形成的軟件邊界都很清楚,溝通也很高效,業務團隊和對應的軟件開發團隊能夠形成合力,共同解決該團隊的業務問題。這實際上形成的還是一顆樹。
 
由以上對比可見,情況3是最好的狀況。每個業務部門形成了一個軟件開發團隊,這個軟件開發團隊為這個部門生成相應的軟件,提升該部門的價值。當然,如果業務團隊內部劃分為多個子團隊,軟件開發團隊也一樣劃分相應的內部子團隊,一一對接,生成相應的軟件。從這個意義上來說,軟件開發團隊其實應該是和業務部門在同一個部門的。當業務組織發生變化的時候,軟件開發部門也應該要有相應的變化,否則就會變成情況1或者情況2的結果了。這就是業務組織架構對開發團隊組織架構的影響,順從這個影響,溝通協作就會很順。反之則需要大量的資源來糾正這些問題,表現出來就是沖突頻繁,內耗嚴重,每個人都很累,但是成效都不大。
 
軟件的拆分
 
同樣,軟件是軟件團隊的產出物(軟件:是指一個可以單獨部署運行的完整產出物,組件:軟件的組成部分,一般是一個獨立開發的單元,不可以單獨運行。軟件可以由一個或多個組件組成,形成一顆依賴樹),對于軟件開發團隊和軟件的關系,也有以下三種情況:
 
情況1, 多個軟件開發團隊開發同一個軟件。這時對代碼的分支合并的管理要求就非常高,經常會發生互相把對方的代碼沖掉的情況,導致嚴重的線上事故。當這個軟件需求比較多的時候,就會導致排隊上線的情況,拖慢對業務的響應。
 
情況2, 一個軟件開發團隊開發多個軟件。軟件開發團隊內部很難形成明確的分工,導致一個人會同時修改多個軟件,這樣就會導致同一個需求,在既可以放在A,也可以放在B的情況下,讓多個軟件的邊界變得非常模糊,形成不恰當的依賴。
 
情況3,一個軟件開發團隊開發一個軟件。這樣每個軟件的職責非常明確,溝通也會比較簡單,這是最好的狀況。這時形成的還是一顆樹。軟件和軟件之間的關系,反應的就是組織和組織之間的關系,還是一顆樹。
 
當軟件開發團隊發生拆分時,軟件也需要響應的拆分,否則就會變成情況1。當開發團隊發生合并時,這個時候比較難處理,因為軟件不一定合并,容易變成情況2。所以一般軟件團隊開始合并時,往往都是比較亂的。這個時候一定要確保內部的原有分工得以保持。
 
在軟件開發團隊內部,精確到每個人的分工也是一樣的道理,一個組件根據內部的分工(參見第八篇)可以分成不同的職責,有負責業務的開發,也有負責技術的開發,這同樣就導致了組件的分拆,這里限于篇幅,就不一一展開了。所以從軟件團隊到人,人到組件,形成的還是一顆樹。軟件和組件,組件和組件之間,形成的也是一顆樹。
 
軟件開發的基礎技術方面
 
當軟件開發進行到一定的程度,每個部門的軟件開發團隊都會發現很多開發方面共通的東西,因為大家是在同一個公司,大家的東西都是放在同一個網站上的,這時站在整個公司的層面,就會有很多大家都要共同遵守的東西出現。為了避免每個團隊都重復發明輪子,這個時候整個公司的軟件開發團隊也會產生統一的規則和相應的分工:
 
同樣都面臨的技術問題,比方說UED、日志、流量分流、基礎框架、運維等,會專門有獨立的團隊來負責,這樣開發團隊就分成了專門服務于業務的軟件開發團隊和專門服務于技術的軟件開發團隊。
 
如果是共享運維團隊,那么還需要同樣的開發流程保障,也會有獨立的團隊來服務于各軟件開發團隊。
 
所以業務軟件開發團隊就變成了這些技術軟件開發團隊的業務方,也需要相應的組織架構來處理業務軟件開發團隊提出的需求,也是一個樹狀結構。這樣以技術為導向的同學,就知道自己是處在架構的什么位置,就不會有那么多關于技術和業務關系的困惑。
 
對于CEO而言,需要一個CTO來輔助CEO管理軟件方面的事務,管理軟件開發團隊的分工,對于業務軟件開發團隊所共同面臨的問題,建立相應的內部分工,形成軟件開發內部團隊,配合業務軟件開發團隊進行工作。這樣就形成了如下的組織架構和軟件架構:
 
\
以上就是業務組織架構的拆分,如何決定軟件開發團隊的組織架構,進而決定軟件的組織架構。軟件開發團隊又進行內部的分工,分為業務和技術兩類,軟件則分解形成了不同的組件,落實到每個研發人員的身上,形成樹狀的關系。換句話說,軟件架構–把軟件看成虛擬的人–實際就是虛擬人的組織架構。架構拆分的原則就來自于業務自身的組織架構,使得軟件架構保持和業務組織架構的匹配關系。
 
如果不認識到這么深遠的影響來源,我們在進行軟件開發活動的時候,一定會遇到很多的麻煩:關系錯綜復雜,難以理清,失去控制。一旦從源頭入手整理,一切都清楚了。如果新接手一個團隊,搞清楚這些也有利于快速展開工作,并可以在自己的范圍之內,嘗試調整好這些關系。對于領導而言,調整好這些關系,事半功倍。
 
軟件拆分的第二動力
 
前面我們已經知道,按照業務組織架構,軟件分拆為相應的架構。我們就可以把軟件當成一個虛擬的人,把軟件認識為虛擬人的組織架構。當軟件上線后,軟件就有了身體,成了一個”真實”的人。當流量進來之后,軟件就開始服務于用戶的請求。隨著流量的增大,軟件就會遇到和人同樣的問題,一臺機器的負載有限,那么就開始增加機器來增加處理能力,或者一個軟件開發團隊的需求量過多,就開始分拆團隊,進而分拆軟件,這就是scale out。
 
但是當機器達到一定的量之后,仍然會遇到瓶頸,這個時候就會開始考慮對軟件進行進一步的分拆。此時就需要分析業務的場景,把該軟件所處理的業務分拆成一個樹狀結構,分散對機器的壓力。這個樹狀結構就是該軟件所形成的子樹,同時也不能違背之前所述的組織架構拆分原則。
 
綜上來看,影響軟件分拆的動力都是流量的增長,也就是希望單位時間內可以處理更多的業務。一方面流量增長導致了業務本身的拆分,進一步導致了軟件的拆分;另一方面,某個軟件本身流量的增長也會導致該軟件自身的拆分。根本問題都在流量的增長上。從這個角度來看,流量增長是企業都追求的目標,只有更多的流量,業務才能夠做大,良好的架構是流量增長的保證。
 
架構一步到位?
 
很多人就會說這太麻煩了,可不可以把軟件架構一步到位地做好?基本上這是不太可能的。一方面在流量不大的時候,做太復雜的拆分會浪費大量時間和不必要的成本;更重要的是因為流量是外在的因素,有經驗的人可以做出部分預判,但也沒有辦法完全預測流量會在哪個地方增長。所以既沒必要一步到位,也不可能一步到位。只能結合運維和運營,及時地探測到流量的增長,在流量達到瓶頸之前,根據業務的規律進行合理的拆分,幫助快速的應對增長。同樣,我不把這叫做架構演化,因為業務并沒有發生變化,只是流量增長,把這叫做軟件的長大可能會更合適一點。
 
以上所說的是軟件拆分背后的原則和原理,也可以說是一個理想情況?,F實工作中我們遇到的往往和這個理想情況差距很大。對于我們每一個人來說,理解這些背后的原則,可以讓我們在復雜的情況下不再迷茫。如果我們每一個人在自己的能力范圍之內,嘗試往這個方向努力,真正的為軟件開發的環境帶來改變,這就善莫大焉了,這篇文章的目的也就達到了。

第二十八屆CIO班招生
法國布雷斯特商學院MBA班招生
法國布雷斯特商學院碩士班招生
責編:yangjun
日本熟妇色在线视频