從系統的組織和部署結構方面來看，軟體架構的演化程式顯然有著從簡單到複雜的趨勢。那是否最新最複雜的架構就是目前業界選擇的最佳架構呢？非也。沒有最好的架構， 只有最合適的架構。在軟體架構的選擇上，”合適“比新更加重要。
對於整個軟體架構發展程式，我們可以大致分為三大階段： 單體架構、 SOA架構、 微服務架構。今天就來簡單分析一下架構的發展與優劣勢，希望能對大家的專案開發有所助益。
（1）單體架構
單體架構就是把所有的業務邏輯和控制邏輯全部都放在了一起，一個程式裡包括了所有的相關功能。（All in one）。比如一個 ERP 系統中包括了商品模組，訂單模組，銷售模組，庫存模組，報表統計等等。
但缺點也很明顯，每次修改程式碼都心驚膽戰，甚至新增一個簡單的功能，或者修改一個BUG都會造成隱含的缺陷。一旦某一個模組出了問題，那基本就是全盤 GG。如果想針對某個具體模組提升效能，難度也比較大。
總的來說單體架構前期開發成本低、開發週期短，適合小型專案。對於大型專案來說不易開發、擴充套件和維護。技術棧受限，只能使用一種語言開發。系統效能擴充套件只能透過擴充套件叢集節點，成本高。
單體架構優劣勢：
|
優勢 |
劣勢 |
|---|---|
|
|
（2）面向服務架構（SOA）
隨著業務系統越來越複雜，單體架構垂直拆分演變出了SOA（ Service-Oriented Architecture），即面向服務的架構。它可以根據需求透過網路對鬆散耦合的粗粒度應用元件(服務)進行分散式部署、組合和使用。一個服務通常以獨立的形式存在於作業系統程式中。比如上面舉的這個 ERP 系統，可以按照功能，將使用者，商品，交易等不同的部分拆分為了獨立的服務（當然，資料庫也需要進行拆分）。
聽起來這種方式比之前的單體架構厲害了不少，但還是會有一些對應的問題，比如每一個拆分之後的服務“依然還是單體服務”，有一些每個模組中都會使用的公共模組沒有拆分（這也會導致 ESB 比較複雜）。
總結來說，面向服務架構有這些優劣勢：
面向服務架構優劣勢：
|
優勢 |
劣勢 |
|---|---|
|
|
3）微服務架構
那如果我們不僅按照垂直方向拆分，同時也按照水平方向進行進一步拆分，那也就是微服務的架構模式了，微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。這些小應用之間透過服務完成互動和整合。其實和 SOA 架構類似，微服務是在 SOA 上做的昇華。
那麼也就是說，微服務其實就是在移除了 ESB 之後，更為輕量和更為松耦合的服務，並把 ESB 的控制邏輯以 SDK 的方式注入到每個微服務中進行服務控制和治理，架構更為的分散式。
由於微服務的要素之一就是“微”，所以大多數微服務都是基於容器進行排程管理的（這也是我們為什麼經常會在微服務的相關介紹中看到 Docerk，k8s 的相關字樣）
微服務架構優劣勢：
|
優勢 |
劣勢 |
|---|---|
|
優勢 |
劣勢 |
|
|
從工作到現在經歷過大大小小的幾十個專案，每個專案都會基於當前的專案階段、技術情況去選擇合適技術架構。（很多大型企業的應用目前都還是單體架構）。隨著技術的發展，隨著業務的發展App版本不斷迭代，新功能不斷增加，業務上的處理邏輯越變越複雜。許多企業可能都面臨著是否要將單體架構進行微服務升級改造的問題。但從一個大一統的系統，拆分成一個一個單獨的小服務，企業需要投入的人力、物力、財力是非常巨大的。在沒有足夠的資源投入之前，不妨選擇一些折中的方案。
傳統架構的最大問題就是緊耦合，在應用迭代、升級的過程中，除了升級微服務架構之外，選擇一些可插拔式的技術工具也可以很好的解決問題。比如： FinClip小程式容器技術 ，這是一種以小程式技術為載體，發展成組裝式的企業應用架構技術。
從應用層來說，只要把 FinClip SDK嵌入到企業的App中，就能立刻獲得小程式執行能力。不管你的專案是什麼軟體架構，都可以透過這種嵌入式的小程式技術去獲得APP並行開發、熱更新、敏捷迭代的能力。
從開發角度來說，這是一種「Native + 小程式」的混合開發模式，藉助這種模式可以讓小程式執行在自有 App 中，將臃腫的 App 功能打散，功能模組互相解耦實現模組化開發，各業務模組間互不影響，透過管理後臺即能實現實時動態更新與釋出。對於一些積重難返的專案來說，採用這種入侵性小、可插拔式的技術是一種值得嘗試的解決方案。