淺談多層技術架構與企業技術競爭力的構建

最近筆者在公司內部做了關於未來技術架構演進的分享，在這裏重新整理一下，希望對讀者有所啓發。

一個企業的良好發展，離不開其核心競爭力。在技術上來說，需要構建技術競爭力，一個擁有技術競爭力的企業，能更好的為業務服務，更好的吸引優秀的技術人員，最終形成一個良好的閉環，技術競爭力轉化為驅動力，讓企業更快更穩的發展。

本文嘗試通過多層技術架構入手，旨在探索一種方式，構建企業技術競爭力，通過技術提高生產力甚至顛覆業務組織形式。

什麼是多層架構

所謂的多層技術架構，就是通過合理的層次劃分，將一個企業的整體技術架構分為多個層次，層與層之間相對獨立。通過分層，實現每一層的平臺化，底層向上層提供服務能力，上層而無需瞭解底層執行細節。

分層是一個縱向的概念，與之對應的橫向是分模組，層是一個更大的概念，每層可能由很多模組組成。當然兩者的很多理念都是類似的，都是通過良好的封裝，降低耦合實現高內聚。

如何劃分多層架構

我們先來看一張圖：

在這張圖中，我們將整個技術架構劃分成了7個相互獨立的部分，下面分別介紹：

資源管理層

在雲端計算技術興起後，各大雲服務廠商（比如阿里雲，AWS）通過使用虛擬化技術簡化了計算資源的管理，實現一鍵建立雲主機，並靈活擴容，不再需要以前託管伺服器，手動管理伺服器的總總工作，大大提高了的生產效率。

最近幾年，隨著輕量級容器技術的應用，Docker 風聲水起，資源管理變得更加的容易和輕量，比如通過 Kubernetes 能夠實現按需更靈活快捷的資源管理，從而更方便的組建公司級 PaaS 平臺。

對於一般的企業而言，這一層更多的利用現有技術為主，包括使用已有的 IaaS 雲平臺和開源的資源排程工具。

平臺服務層

如果說資源管理層是我們的作業系統，那麼平臺服務就是我們的 libc 基礎庫，有了它的存在，讓我們更加方便的的構建雲端上層應用，讓上層應用專心關注業務，而不需要關心和維護底層平臺。

那哪些服務可以劃分爲平臺服務呢？我覺得平臺服務應該滿足以下幾個特點：

1. 適用面廣，平臺服務應該有及其廣闊的使用場景

2. 抽象度高，平臺服務應該是高度抽象的，為業務提供基礎能力

按照這個標準，如下這些服務都可以歸為平臺服務：

1. 佇列服務

2. 推送服務

3. 物件儲存與處理服務

4. 中心任務排程服務

5. 等等

這一層中，很多的雲廠商都提供的對應的產品，如果沒有特殊要求，拿來就可以使用。

基礎服務層

相比平臺服務，基礎服務更偏業務，它是對不同型別業務的抽象，雖說它的抽象程度和通用性不足平臺服務，但其給開發者的方便程度確是很大的，如果抽象合理，應用得當，能夠極大的提升開發效率。

基礎服務層可以對標  BaaS （後端即服務），通過基礎服務層，我們將涉及的業務進行更巨集觀全方位的抽象，設計出一個更通用的基礎服務，避免相類似的業務被重複的實現了多次，提高技術含量，技術價值最大化。

就筆者所在公司的 SaaS 系統而言，如果下的一些服務都是可以做成基礎服務:

1、使用者與許可權服務

使用者與許可權管理是每個系統都必不可少的功能 ，其結構大同小異，如果將其獨立成一個基礎服務，讓不同產品都可以使用，讓新產品的開發更方便快捷。

2、表單服務

對於很多產品而言（toB 產品尤甚），我們大量的工作都在處理各種表單，處理起來繁雜冗餘，技術含量不高。如果我們提供同一的表單引擎，統一管理和設計表單，並提供配套設施，將大大提高工作效率。

3、流程引擎

在表單服務的基礎上，再輔以流程引擎，讓資料在不同的流程中流轉起來，匹配業務流程。如此便可以不編寫程式碼或者只需少量程式碼就能實現一個自定義的業務流程。

4、資料分析服務

有了表單服務和流程引擎還不夠，如果再結合資料分析服務，讓資料是可以通過各種方式被分析，就可以讓資料產生更大的價值，幫助決策。通過保單服務、流程引擎、資料分析服務的完美結合，我們有機會以更方便快捷的方式，滿足客戶需求。

基礎服務層是對業務的高度抽象，不同的業務形態可能形成不同的抽象，通過基礎服務層的建設，讓上層業務的開發就像搭積木一樣，通過組合，更快的響應客戶需求，同時避免開發人員疲於奔命。

業務層

有了前面的支撐，業務的開發就顯得簡單多了。當然爲了最終服務的可靠性，在設計業務服務的時候，需要考慮以下幾個原則。

隔離性

不同的業務服務直接應該具有一定的隔離性，防止因一個服務故障而將其他服務拖垮的情況。對於一些有突發流量的服務，應該考慮增強其獨立性，從而減少對其他服務的影響。

無狀態

業務服務應該是無狀態的，這樣方便服務的水平擴充套件，通過橫向的機器擴充套件實現高併發的需要。

服務降級

故障必不可免，如果如果其他服務發生故障，可能需要設計一定的降級措施，避免服務發生聯機失敗，減少損失。

接入層

對於原來的單塊應用來說，接入層很簡單，只有簡單的 DNS 加上 Nginx 做一個反向代理。但當我們的服務越來越多，變成一個複雜的分散式系統的時候，接入層的存在就顯得必須且非常重要了，接入層從外到內，有如下幾個層級：

1、DNS

接入層的最外層是 DNS，通過智慧 DNS 解析，給不同的區域，運營商分配最合適的線路，達到訪問最優的效果。當然 DNS 還能做負載均衡，只是因為 DNS 的更新策略問題，不能做到及時恢復，一般我們需要配合負載均衡使用。

2、負載均衡

負載均衡分為四層負載均衡和七層負載均衡。

四層負載均衡是工作在 TCP/IP 層的負載均衡器，比如  LVS，因為工作在四層的原因，這裏的負載均衡效能好，但靈活性不是很高，如果不是特別大規模的應用，這一層可能不需要。

七層的負載均衡能夠解析具體的協議，比如 HTTP，能夠根據請求的資訊靈活的定義規則，比如進行簡單鑑權，比如統一新增 RequestID。常見的 Nginx、HAProxy 都可以作為七層負載均衡。

通過負載均衡器，我們可以實現：

1. 負載均衡，將請求按需分配到不同的服務例項上，實現故障轉移和高可用

2. TLS offloading，將外部的 HTTPS 流量轉成內網 HTTP 流量

3. 限流，讓後端服務始終工作在最高效的狀態

4. 簡單鑑權處理（七層）

5. 異常流程檢測，IP 遮蔽

6. DDoS 防護

3、WAF

WAF 是 Web 應用防火牆，現在的網際網路充滿了太多的不安全因素，於是 WAF 應運而生，WAF 通過規則或者學習的方式識別惡意請求，讓它們沒有機會到達後端伺服器，保障 Web 安全。

WAF 可以在七層負載均衡器中實現，有的 WAF 有附帶負載均衡的功能。

資料層

上面的幾個層中，它們大多的服務都是沒有狀態的，這使得它們具備良好的 擴充套件性。但在真實的世界中，有許許多多的狀態和資料需要被持久化的儲存。

通過引入資料層，將資料儲存服務化，業務無需關注資料儲存的底層細節，比如備份，容災，擴充套件性。

當然，構建這樣一個數據層就需要考慮很多東西，包括但不限於如下幾個方面：

1. 資料備份與恢復，容災相關考慮

2. 水平擴充套件性，支援大量和大併發的資料儲存（分散式儲存 or 中介軟體）

3. 完善開發工具支援，方便業務方定位問題

最後，資料層也會細分很多的服務，比如關係型資料庫，文件資料庫，快取，佇列等，不同的應用場景需要不同的資料層支援。

監控層

我們的服務時刻面臨挑戰，有來自使用者突發流量，有來自攻擊者的惡意流量，有研發團隊迭代產生的問題，不一而足。

爲了讓我們更快的發現問題，進而解決問題，監控是保證高可用服務比不可少的支撐系統，其重要性不言而喻。通過監控可以：

1. 最基本的反應系統的健康狀態

2. 出現問題時分析問題出現的原因

3. 自動擴容與故障處理

4. 作為系統優化的資料資料支撐，比如效能優化

5. 更甚一步，通過監控建立業務模型(呼叫鏈)，實現故障的根因分析（AiOps）

多層架構優勢與可能性

建設多層技術架構體系，我們有如下幾個方面的優勢和可能性：

更好的分工協作

通過技術架構，把涉及的有所工作進行統籌劃分，特別是團隊比較大的時候，讓每個團隊都能夠在既定的上下文中工作，降低溝通成本，同時減少重複造輪子，實現技術共享。

提升技術競爭力

筆者相信，一個優秀技術人員更希望從事有挑戰的工作，通過越來越大的挑戰，實現個人能力的提升。

作為企業也是一樣，我們需要為他們提供這樣的環境，能夠讓技術人員有機會接觸這樣的挑戰，最終企業與個人達到一個良好的化學反應，提升企業與個人的綜合技術競爭力。

顛覆業務形態

技術發展到一定程度，它可能不僅僅能為我們提高效率，它還可能是創新的土壤，有機會顛覆已有的業務形態或者發現更多的機會。

比如說，亞馬遜作為一家電子商務公司，它的 AWS 雲端計算服務世界第一；再比如說，Salesforce 作為 TOP 1 的 SaaS 公司，對外開放了技術能力，讓人可以方便的構建應用，滿足不同的應用場景。

通過技術創新，它們已經顛覆了原本的樣子，與競爭者不在一個維度。雖然這可遇不可求，但夢想還是要有的，萬一實現了呢~

本文到此結束，更多精彩文章，盡在「程式碼寫詩」，微信搜尋「 程式碼寫詩 」公眾號即可關注。