再談什麼是軟體架構

「什麼是軟體架構」，這個主題在這個專欄中已經談過一次了：

什麼是軟體架構 - 知乎專欄

其實看你從什麼角度入題了，這個問題可以談很多次。這次我們從分析現有軟體的的角度討論什麼是「軟體架構」。我們從這個博客討論的問題說起：

RancherOS架構分析 - 知乎專欄

下面有人問到：「什麼是軟體架構？你寫的這些知識又是如何獲取的呢？」

從我寫那個分析的思路上說，我定義軟體架構是：所有可以左右軟體發展方向的事實的集合。

我準備引入一個軟體，投入一起開發一個軟體，我需要看到一個軟體會不會把自己給弄死了，或者它最終會不會走向我期望它走向的方向。這一方面來自這個軟體的全部維護者的「理想」，另一方面來自這個軟體已經進入的現實。所以架構分析，就要弄清楚這些人的理想和現實，綜合判斷它是否可以支持我的個人理想的實現。

所以，我分析這個軟體，第一反應是它的維護者是如何定義這個軟體本身的，這通過看它的主頁就可以了：

我看到兩個關鍵字：Management和Production。現在我看它賣什麼，靠什麼賺錢，公司有多少人，這決定了它的投資模式（實際上這部分我藏了私，我沒有放在博客中，這也是NDA的要求）。

然後我就發現它是個開源項目，所以，我git clone了它的代碼（當然我們都知道，開源項目和一個公司要賣的東西不一定一樣）。然後查看它的版權聲明，編程語言，代碼量等。

到此為止， 我從「理想」角度，對這個軟體有了一個基本的認識。在進一步了解軟體已經建成的狀態以前，我需要先自行建一個邏輯：如果我來干這件事，我會怎麼干：

我簡單設想，我會Rebase一個已有的發行版（我很可能選擇Debian，因為我熟悉Debian，而且我可以利用Debian的升級基礎來實現我的版本的持續維護），然後我會寫一組命令，用於在Container的基礎命令之外執行經常會執行的動作。Debian的安全按一般定製發行版的方式實現，命令用Python來組織（用Python是因為我熟悉Python，同時它提供了足夠的腳本能力），最後就是我可能會自己創建一個Registry來提供我自己認證的Image服務。

然後我會從這個角度來對它的實現進行對照，這個我可以通過在虛擬機中安裝和查看這個產品來達成。

所以我按它的手冊的建議安裝了一個系統，首先在它的Host上用tree來看它大部分的文件分布和文件來源。這樣很容易就可以發現如下重要的事實：

1. 它的基礎發行版用的是busybox+uclibc，這個，作為一個有發行版組織經驗的人，你應該清楚，這很可能直接可以用ucblic本身的buildroot就可以實現了，而且很容易實現多版本的支持。唯一的工作量是把docker的命令集成進去。也知道它每次生成一個啟動的iso的工作量有多大了。

2. 然後看看它額外增加的busybox之外的命令的版本和使用的庫，就可以知道它是基於uclibc的工具鏈進行每個獨立編譯得到的

3. 然後我們用ps看正常運行的系統的進程表，可以看到Host上提供了什麼服務

4. 接著安裝兩個典型的Image（我裝的是CentOS和Ubuntu），一個安裝了一個Apache，一個編譯了一個Linux Kernel。大概了解一下它的成熟度和使用的Registry

5. 最後，從源代碼最後看一次ros命名的功能和大概組成，通過strace跟蹤一兩個命名設計的系統文件和系統調用，就可以知道有什麼額外的信息需要了解。

這樣之後，能否維護，未來這個方案會如何發展，就有初步的理解了。

順便說一句，在分析的過程中，我其實還通過mount看了一下它的文件系統layout，對/etc/hostname被mount到/dev/sda1上非常不理解，所以我花了一點時間看了一下mount的手冊和對應的代碼，然後總結成一個獨立的描述：mount --bind 可以算是ln一個目錄么? 。我手上有無數這種分析，一般我會寫在evernote上，但前天正好在機場等飛機，寫的時候手邊訪問evernote不方便，所以就改寫到知乎上了。我舉這個例子是說，其實架構師手邊是有大量的分析數據的，但必須能保證這些分析不會隨意進入主分析鏈，避免目標被沖淡了。所以，你看到一點點的決策或者判斷，實際上可能背後都是大量的工作。