後端架構演進

後端架構演進

在公司已經走過不少個年頭，有幸可以親手去創造架構組，甚至帶領團隊去完成部分架構的調整，驗證架構的想法。但願可以獲得大牛們的一些指引。

1.0 時代

傳統的 LNMP 架構，雜亂的應用體系，數不清的坑。單體應用的狀況下還能夠接受，一旦業務發展速度加快，人員不到位，就可能出現這種狀況。

這個結構至關簡單，數據庫在本機，業務代碼也在本機，一臺機子上有不一樣的項目。

2.0 時代

雖說 2.0 時代有了我們自身的數據庫服務器，名義上將數據庫與業務代碼進行分離，可是服務器還有不少不一樣的業務代碼，還可能相互影響着。

隨着時間的推移，這樣的結構愈來愈複雜，每一個業務中甚至還穿插着其餘業務，維護尤爲的累與危險。

3.0 時代

正式提出將業務進行模塊化處理，將公共的模塊獨立成一個基礎的組件運行，並由其負責獨立處理。

整個過程相關因而將不少業務進行調整，其中涉及的量還很多，而且須要推翻了部分業務的流程，可謂是一個大工程。

自從將業務組件拆分以後，維護起來也相對容易了一些，可是由於拆分了，說明數量增多了，維護的成本也相對較高。

4.0 時代

雖然將組建都拆分了處理啊，可是業務上仍是相對雜亂的，因而，咱們就從新將業務進行編排，而且加入了網關 + 內部DNS服務器，用來解決端口氾濫的問題。

咱麼協議目前仍是是用HTTP協議進行通訊。

總結

這個架構演進主要是爲了解耦業務，釋放人力去將業務作得更加精細，提供業務質量。可是解耦意味着人力投入的增長，因此須要適當考慮當前是否適合進行這樣的架構調整。

問題:

• 資源編排: 想要將業務作得更加獨立，就須要從新對資源進行編排，獨立的業務，獨立的資源

• 服務超時: 拆分以後的業務調用更加複雜，當其中一個鏈路出現問題的時候，可能會影響整個調用過程出現問題，因此適當的超時處理是必須的。

• 增長監控的難度: 由於服務多了，調用的關係鏈更加複雜，須要定位到具體服務器，具體代碼，則須要引入調用鏈監控的環節，目前使用到的是 fiery