小公司做業務服務，需要聚焦到實際的業務上，盡快通過業務服務客戶，給客戶創建價值，公司才能生存下去。在技術上采用的Web應用架構具備以下特點：

• 主要由開源組件組裝而成。這樣既可以節省成本，也可以把時間聚焦到實際的業務當中，盡快實現業務。
• 需要功能豐富，能夠支持業務快速開發。數據量雖然不一定大，但業務可能很多，關系型存儲、非結構化存儲、文件存儲、關鍵字搜索、任務調度、消息中間件等一個都不能少，每個都需要用。

• 不需要支持大的“量”級。大多情況下不涉及大數據、高并發之類的，不能過度設計。
• 成本要低。不能采用耗費資源過大的組件，客戶服務器預算有限，大多只能提供一臺或者一個雙機的服務器。

這里把這種架構成為“小架構”，這個“小”主要是指小型，其內涵是很豐富的，其核心是要支持業務快速開發，功能豐富且好用。

為了支持業務快速開發，僅僅把一系列開源組件組合還不夠，還需要：

• 提供一個工程模版，把程序的啟動、參數/返回值處理、異常處理等都規范好，可以直接開發業務。
• 把開源組件的配置、啟動等封裝起來，給業務提供能夠之間使用的服務。比如消息中間件，業務注入一個服務就可以發消息，不需要關心下面用的到底是Kafka還是RocketMQ，也不關心它們是如何配置的，如何啟動的。
• 提供一些通用的服務。有些是用開源軟件不夠易用的需要封裝一下，有些沒有開源軟件提供能力的則自研一個。
• 提供一套規范，大家在這規范下可以快速開發出一致的、易維護的代碼，也能夠減少一些踩坑的情況。

這系列“小架構”的文章就主要是講解如何搭建這種“小架構”的，以及了解相關原理。

在一家公司里，受限于人力有限和維護成本，從零建設架構的機會一般是很有限的，不太會每個項目都重頭搞個不同的架構，這對公司的發展和維護是非常困難的。這意味著在一家公司里，能夠接觸到架構變更的機會是非常有限的，可能待很長時間都不一定有一次。架構的變動也是慎之又慎，畢竟底層的東西影響范圍比較大。當時間長了，架構本身就會積累很多東西，也就更加難改變了。

自己在一家公司待的時間很長，經歷過幾次架構改動，架構有在逐步迭代完善。但還是有不少東西受限于歷史原因和業務當時的限制而不得不做的妥協，留下了各種各樣的“遺憾”。經常會有點小小的感慨：如果這個能一開始就做好一點就好了。所以面對這種感慨，自己萌生了有沒有可能重頭再寫一個的想法。在工作上不好說什么時候能有這種機會，但在業余上則是可以嘗試一下，把自己的一些心得實踐一下，也把一些自己覺得“遺憾”的地方糾正一下。

做一件事情時間長的好處是這個事的全流程基本了解，里面有哪些坑和如何折中解決的也都了解。但也有個缺點，就是每次的迭代都是碎片化的，一個個知識就像一顆顆小珍珠一樣散落到各個地方，總是感覺差一根繩子把這些零散的珍珠串接起來形成一個項鏈，也就是一個知識的體系。

借這個機會則可以把這些知識重新整理一下，把自己的一些思考記錄下來，修正一些自己覺得不太好的地方，把自己之前了解的原理片段串聯起來，從而形成一個小知識體系。

這種小架構，麻雀雖小卻五臟俱全，要把里面的知識整理清楚，并不容易。一個東西好像是理解了，但如果要把它有條理的表達出來，難度就不在一個檔次了。自己實際經歷的不少東西是歷史沉淀下來的，歷史的局限也在里面，要把它的一些局限更換掉，既需要對局限的內容深入了解，也要鉆研一些新的知識，才能把這些局限更換掉，這需要花不少時間。而在工作之外，時間本來就比較少，要把這個事情做成，挑戰也比較大，需要自己給自己一股擠時間的勁，額外擠出足夠的時間才有可能完成這個事情。把這個事列出來，也算是有一股監督的力量來推動一下自己。

筆者并沒有研究過各個公司的架構，很多理解也僅是一家之言，所以這系列的文章有比較多的局限性，整理出來既可以供大家參考，也可以向大家學習。歡迎交流和指正。