架構設計的宏觀視角

今天咱們來談談架構設計的宏觀視角。

在信息科技高度發展的今天，咱們每一個人隨時隨地均可以接觸到由程序驅動的智能電子設備，包括手機（如iPhone、oppo拍照手機）、平板電腦（如iPad）、手錶（如iWatch、小天才智能手錶）、音箱（如天貓精靈）、汽車（如特斯拉）等等。

這些東西背後是怎麼工做的？單就其中的軟件系統而言，這些小小的設備上每每運行着成千上萬個軟件模塊，這些模塊是如何如此精密地一塊兒協做的？

對此，我過去接觸過不少的軟件開發工程師，或者架構師，不少人對這些原理也是隻知其一;不知其二，雖然「知其然」，但卻「不知其因此然」。甚至有些朋友可能以爲，學這些有什麼用處呢，在我看來，這部份內容偏偏是咱們成爲架構師很重要的一門基礎課。

爲何須要創建宏觀視角？

如同造房子有建築工人（負責搬磚）和建築師（負責架構設計）同樣，軟件系統的開發過程一樣須要有程序員（負責搬「磚」）和架構師（負責架構設計）。做爲架構師，咱們須要的第一個能力是宏觀的全局掌控能力。

若是把應用程序比做一座大廈，那麼咱們做爲大廈的架構師，須要把大廈的結構搭建好，讓程序員能夠把磚填充進去，咱們都知道，一個大廈的結構建得是否穩固，與地基密不可分。

因此，咱們首先就須要從大廈的地基開始，熟悉這座大廈。畢竟，你對所依賴的基礎架構瞭解得越全面，作業務架構設計就會愈加從容。

介紹基礎架構的知識點並非讓你真的去實現它們。但你仍然須要懂得它們的核心思想是什麼，知道有哪些信息是你必須深入理解的，以即可以更好地駕馭它們。

騰哥：基於容器構建EFK海量日誌系統 (2020-03-22分享筆記)
你們自取（點擊原文，加入社羣）
https://www.yuque.com/docs/share/0b637cb3-104a-441f-8438-3b3504445c89?#

咱們的整個專欄內容也會從基礎架構開始講起，最後逐步過渡到業務架構，到最終完成一個完整應用程序的設計過程。

那麼，在今天的開篇第一篇，咱們須要站在宏觀視角，從基礎架構開始，逐漸來解剖一個應用程序的總體構成，我但願，經過今天的文章，可讓你對於一個程序的全貌，造成完整的認識。

咱們從頭開始。

應用程序的基礎架構

咱們想學習一個程序的基礎架構，其實就是弄清楚電腦的工做原理，以及程序的運行原理。

不管是什麼樣的智能電子設備，手機也好，汽車也罷，它們均可以稱爲「電腦」。全部的電腦均可以統一看做由「中央處理器+存儲+一系列的輸入輸出設備」構成。

中央處理器，也就是咱們日常說的CPU，負責按指令執行命令；存儲負責保存數據，包括咱們要執行的命令，也是以數據形式保存在存儲中的。

每次在打開電腦的電源後，中央處理器都會從存儲的某個固定位置處開始讀入數據（也就是指令），而且按指令執行命令，執行完一條指令就會繼續執行下一條指令。電腦就這樣開始工做了。

你可能會說，就這麼簡單？是的，就是這麼簡單。

那這麼簡單的話，爲什麼電腦可以完成這麼多複雜而多樣化的工做？

這整個過程，在我看來主要依賴兩點。

第一是可編程性。大致來講，中央處理器（CPU）的指令分爲以下這幾類。

• 計算類，也就是支持咱們你們都熟知的各種數學運算，如加減乘除、sin/cos等等。
• I/O類，（從存儲讀寫數據）從輸入輸出設備讀數據、寫數據。
• 指令跳轉類，在知足特定條件下跳轉到新的當前程序執行位置。

雖然， CPU 指令是一個頗有限的指令集，可是CPU 執行的指令序列（或者叫「程序」）並非固定的，而是依賴保存在存儲中的數據—— 由軟件工程師（或者叫「程序員」）編寫的軟件來決定。指令序列的可能性是無窮的，這也就意味着電腦可以作的事情的可能性也是無窮的。

第二是開放設計的外部設備支持。雖然咱們電腦能夠鏈接很是很是多種類的外部設備，好比鍵盤、打印機、屏幕、汽車馬達等等，但CPU 並不理解這些設備具體有什麼樣的能力，它只和這些設備交換數據。它可以作的是從某個編號的設備（一般這個設備編號被稱爲「端口」）讀入一段數據，或者向設備的端口寫入一段數據。

例如，當你在鍵盤上按下了A的時候，CPU 能夠從鍵盤鏈接的端口讀到一段數據，經過這段數據來表達你按了「A」，可能CPU 會向打印機鏈接的端口發送一段數據，來驅動打印機打印特定的文本；還有可能CPU 會向汽車馬達所在的端口發送數據，來驅動馬達轉動，從而讓汽車按照預期來行駛。

值得注意的是，CPU 知道的是如何和這些設備交換數據，可是並不理解數據表明什麼含義。這些外部設備的廠商在提供設備硬件的同時，每每也須要提供和硬件匹配的軟件，來完成和CPU 的協做，讓軟件工程師能夠輕鬆使用這些設備。

從上面能夠看出，電腦的 CPU 是一個很是簡潔的模型，它只讀入和寫出數據，對數據進行計算。這也是爲何咱們每每把電腦也叫做「計算機」，這是由於 CPU 這個計算機的大腦的確只會作「計算」。

這個基礎的設計體系，咱們不少人都知道，這就是馮·諾依曼計算機體系。1945年6月，馮·諾依曼以「關於EDVAC的報告草案」爲題起草的長達101頁的總結報告，定義了「馮·諾依曼體系結構」，他如今也被稱爲計算機之父。我想看到這裏，你應該不難理解他的偉大之處了吧？

有了這個基礎的計算機體系以後，咱們就能夠編寫軟件了。

固然咱們遇到的第一個問題是直接用機器指令編寫軟件太累，並且這些機器指令像天書同樣沒人看得懂，無法維護。

因此，編程語言+編譯器就出現了。編譯器負責把咱們人類容易理解的語言，轉換爲機器能夠理解的機器指令，這樣一來就大大解放了編寫軟件的門檻。

在編寫軟件不是問題時，咱們遇到的第二個問題，就是多個軟件在同一個電腦上怎麼共處。多個軟件你們往同一個存儲地址寫數據衝突怎麼辦？一塊兒往打印機去發送打印指令怎麼辦？有的軟件可能偷偷搞破壞怎麼辦？

因而，操做系統就出現了。

它首先要解決的是軟件治理的問題。它要創建安全保護機制，確保你的電腦免受惡意軟件侵害。同時，它也要創建軟件之間的協做秩序，讓你們按照指望的方式進行協做。好比存儲你寫到這裏，那麼我就要寫到別處；使用打印機要排隊，你打完了，我才能接着去打印。

操做系統其次解決的是基礎編程接口問題。這些編程接口一方面簡化了軟件開發，另外一方面提供了多軟件共存（多任務）的環境，實現了軟件治理。

例如，對於屏幕設備，操做系統須要提供多任務窗口系統，以免屏幕被多個軟件畫得亂七八糟；對於鍵盤輸入設備，操做系統引入焦點窗口，以肯定鍵盤輸入的事件被正確發送到正確的軟件程序。

你會發現，今天的咱們開發軟件的時候，已經處於一些基礎的架構設計之中。像馮·諾依曼計算機體系，像操做系統和編程語言，這些都是咱們開發一個應用程序所依賴的基礎架構。

基礎架構解決的是與業務無關的一些通用性的問題，這些問題每每不管你具體要作什麼樣的應用都須要面對。並且，基礎架構一般以獨立的軟件存在，因此也稱爲基礎軟件。

例如，咱們熟知的Linux、Nginx、MySQL、PHP 等這些軟件都屬於基礎軟件，這些基礎軟件極大地下降了應用開發的難度。在今天軟件服務化的大趨勢下，不少基礎軟件最終以互聯網服務的方式提供，這就是所謂的「雲計算」。

完整的程序架構是怎樣的？

講完了程序的地基，讓咱們來總覽一下程序的完整架構。

在越強大的基礎架構支撐下，應用程序開發須要關注的問題就越收斂，咱們的開發效率就越高。在咱們只須要關注應用程序自己的業務問題如何構建時，咱們說本身是在設計應用程序的業務架構（或者叫「應用架構」）。

業務架構雖然會由於應用的領域不一樣而有很大的差別，但不一樣業務架構之間，仍然會有許多共通的東西。它們不僅遵循相同的架構原則，還能夠遵循相同的設計範式。

一些設計範式被人們以應用程序框架的方式固化下來。例如，在用戶交互領域有著名的MVC 框架（如JavaScript 語言的Angular，PHP 語言的Zend，Python 語言的 Django），在遊戲開發領域有各類遊戲引擎（如JavaScript 語言的 Phaser，C# 語言的 Unity3D），等等。

對於一個服務端應用程序來講，其完整的架構體系大致以下，若是你在收聽音頻，你能夠點擊文稿查看：

對於客戶端應用程序來講，和服務端的狀況會有很是大的差異。客戶端首先面臨的是多樣性的挑戰。

單就操做系統來講，PC 就有Windows、Mac、Linux 等數十種，手機也有Android、iOS，Windows Mobile 等等。而設備種類而言就更多了，不僅有筆記本、平板電腦，還有手機、手錶、汽車，將來只會更加多樣化。

第一個想消除客戶端的多樣性，而且跨平臺提供統一編程接口的，是瀏覽器。

可能在不少人看來，瀏覽器主要改變的是軟件分發的方式，讓軟件能夠即取即用，無需安裝。但從技術角度來講，底層操做系統對軟件的支持一樣能夠作到即取即用。

這方面蘋果在iOS 上已經在嘗試，你們可能已經留意到，若是你一個軟件好久沒有用，iPhone 就會把這個軟件從本地清理出去，而在你下一次使用它時又自動安裝回來。

假如軟件包足夠小，那麼這種行爲和 Web 應用就毫無區別。不一樣之處只在於Web 應用基於的指令不是機器碼，而是更高階的 JavaScript 腳本。

JavaScript 由於指令更高階，因此程序的尺寸比機器碼會有優點。但另外一方面來講 JavaScript 是文本指令，表達效率又要比機器碼低。

但這一點也在發生變化，近年來 WebAssembly 技術開始蓬勃發展，JavaScript 做爲瀏覽器的機器碼的地位會被逐步改變，咱們前端開發會面臨更多的可能性。

瀏覽器的地位很是特殊，咱們能夠看做操做系統之上的操做系統。一旦某種瀏覽器流行起來，開發人員都在瀏覽器上作應用，那麼必然會致使底層操做系統管道化，這是操做系統廠商所不肯意看到的。

而若是瀏覽器用戶量比較少，那麼經過它可以觸達的用戶量就太少，消除不一樣底層操做系統差別的價值就不存在，開發人員也就不樂意在上面開發應用。

咱們知道，PC 的瀏覽器之戰打到今天，基本上就剩下Chrome、Internet Explorer、Safari、Firefox 等。

有趣的是，移動瀏覽器的戰場彷佛是從中國開始打起的，這就是微信引起的小程序之戰，它本質上是一場瀏覽器的戰爭。

瀏覽器是一個基礎軟件，它可以解決多大的問題，依賴於它的市場佔有率。可是基於一樣的瀏覽器技術核心也能夠構建出跨平臺的應用框架。咱們看到 React Native 就是沿着這個思路走的。固然這不是惟一的一條路，還有人會基於相似 QT 這樣的傳統跨平臺方案。

總體來講，對於一個客戶端應用程序來講，其完整的架構體系大致以下，你能夠點擊文稿查看：

對於架構師來講，不只僅只是想清楚業務應該怎麼去作好分解，整個應用從底到最頂層的上層建築，每一層都須要進行各類決策。先作 iOS 版本，仍是先作小程序？是選擇 Java 仍是 Go 語言？這些都是架構的一部分。

結語

今天，咱們從「計算機是如何工做」開始，一塊兒登高鳥瞰，總覽了程序完整的架構體系。

可能有人看到今天的內容內心會有些擔憂：「原來架構師要學這麼多東西，看來我離成爲架構師好遠。」

好消息是：咱們就是來打消這個擔憂的。若是咱們把寫代碼的能力比做武功招式，那麼架構能力就比如內功。內功修煉好了，武功招式的運用才能駕輕就熟。

而架構能力的提高，本質上是對你的知識脈絡（全身經絡）的反覆梳理與融會貫通的過程。具有架構思惟並不難，並且極有必要。無論今天的你是否是團隊裏的一位架構師，對任何一位程序員來講，具有架構思惟將會成爲讓你脫穎而出的關鍵。

這就像你沒有從事雲計算行業，可是你仍然須要理解雲計算的本質，須要駕馭雲計算。你也沒必要去作出一個瀏覽器，可是你須要理解它們的思考方式，由於你在深度依賴於它們。

接下來咱們將進一步展開來談這個程序架構體系裏面的每個環節。你對今天的內容有什麼思考與解讀，歡迎給我留言，咱們一塊兒討論。若是你以爲有所收穫，也歡迎把文章分享給你的朋友。感謝你的收聽，咱們下期再見。

本文分享自微信公衆號 - 架構師智庫（beijing-tmt）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。