簡單聊聊企業應用架構的演變

前言

從計算機誕生到如今其實也就短短几十年, 從最先的軍事使用,到投入商業, 直至如今走入尋常百姓家中。用突飛猛進來形容絕不爲過。 企業的服務框架, 也隨着計算機的發展, 層層迭代, 由最先的單一型應用服務發展至如今知足於幾億甚至幾十億的人民的大型服務

框架的演進

1、垂直型服務

單一型應用

早期, 企業的對外提供的服務比較單一, 客戶流量也相對不足。 所以將全部的模塊，代碼打包在一個項目中，集中部署一臺機器上。

這樣操做簡單粗暴，運維人員只要關注這一臺服務器就了事了。 可是問題來了, 若是服務器宕機了怎麼辦呢, 這不就意味着沒法對外提供服務了嗎?

主備機應用

爲解決上述問題, 倒也簡單, 給每臺機器增長几臺備機不就好了嗎？ 服務器掛掉了， 快速切換服務器，依舊能及時知足對外服務。

但是問題又來了, 企業是在快速發展的啊。 企業的客戶會愈來愈多, 流量愈來愈大, 單單一臺服務器對外提供服務， 哪裏撐得住啊， 不分分鐘被搞掛掉纔怪。

多機服務 + 負載均衡

因而乎， 咱們多增長几臺服務器，經過負載均衡器（F5或者NGINX等）將客戶請求（按負載均衡算法）合理的分配到各臺機器上， 讓各臺機器同時提供對外服務。 這樣每臺服務的器壓力下降了， 能快速和安全的服務於客戶了。 

如今, 因爲咱們提供的服務讓客戶很是滿意, 公司賺錢了, 開始要拓展業務了, 再也不是以前的單一服務了, 咱們要作大作強。 因而咱們須要瘋狂開發新模塊, 對外提供更多的優質服務。 那麼問題來了， 那麼多模塊， 咱們總不能仍是那麼簡單粗暴的擠在單一應用上吧。 開發人員還怎麼愉快的合做了? 代碼合併的時候，還不分分鐘掀桌子? 並且，每臺機器的算力畢竟有限， 全部模塊集中在同一個應用上，不是很不合理嗎?

所以，咱們須要把幾個模塊獨立出去， 造成新的服務。當服務於服務之間存在依賴時， 再讓二者進行交互， 完成數據傳遞。 那服務間怎麼交互呢？ 這就要說說RPC了。

2、基於RPC的服務

什麼是RPC

RPC（Remote Procedure Call）—遠程過程調用，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。

RPC使用

有了RPC 服務間就能愉快的進行數據傳遞了。 咱們的架構就能獲得很好的改良了。

如今咱們的框架分紅了不少獨立的小模塊,模塊間能實時的,有效的進行消息傳遞。 而且業務與業務間獲得很好的解耦， 機器的算力也沒必要再擔憂支撐不起系統了。看起來很完美。

但是，運營人員不幹了: 如今服務那麼分散， 機器那麼多，讓我怎麼管理？哪天哪臺服務掛掉了， 讓我上哪找去？

所以， 咱們須要將咱們的全部服務有效的管理起來.

3、SOA

什麼是SOA

面向服務的架構（SOA）是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）進行拆分，並經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。

阿里巴巴的Dubbo就是一個很是好的服務治理框架, 有興趣的朋友能夠去學習學習。

SOA的使用

經過SAO的服務治理方案, 咱們將咱們的框架進行終極改良。

• 將全部的服務提供者註冊到註冊中心。
• 客戶端向註冊中心訂閱服務
• 註冊中心向客戶端推送有效的服務信息
• 客戶端獲得全部可調用服務的信息後， 根據需求，按負載均衡算法， 進行調用， 獲取數據。

咱們將每次調用狀況都記錄在服務監控組件上，這樣服務的調用狀況，健康情況就一目瞭然了。 更甚者，咱們能夠獨立一個配置中心模塊，如須要修改服務的配置信息時， 經過此模塊實時推送配置信息到全部或者指定的機器上，進行動態修改。 運營人員不再用一臺機器一臺機器的修改配置信息了。

至此， 咱們的框架能夠有效的知足不斷擴張的業務需求以及保證機器的平穩運行了。 到這裏, 框架能夠算是暫時定型了, 短時間內, 不會再作什麼大規模的改造了。

到這裏就結束了嗎?那接下來的微服務又是什麼呢, 還有必要升級嗎?

4、微服務

什麼是微服務

微服務架構的系統是一個分佈式的系統,每一個微服務基本是一個能獨立發佈的應用服務，所以能夠做爲獨立組件升級、灰度或複用等，對整個大應用的影響也較小，每一個服務能夠由專門的組織來單獨完成，依賴方只要定好輸入和輸出口便可徹底開發，甚至整個團隊的組織架構也會更精簡，所以溝通成本低、效率高。

說的微服務, SpringCloud是繞不開的話題, 有興趣的朋友能夠去學習學習。

微服務和SOA的差別 SOA和微服務一脈相承, 都是面向服務的治理方案

• 微服務顆粒度更細, 一個系統拆成多個服務, SOA顆粒度更大
• 微服務功能獨立, 獨立部署; SOA單體架構,業務耦合
• 微服務服務自治, 鬆散管理; SOA集中式管理

隨着敏捷開發、虛擬化技術、DevOps 理論的實踐，微服務架構愈來愈被重視與應用。 可是成熟的企業,已有成熟的架構, 徹底不必冒風險進行微服務改造。 總的來講二者都有各自的優點, 具體如何使用, 則根據各個企業自身的考量。

總結

本文不嚴謹的介紹了企業框架演變的過程。

你們發現沒， 每次的架構變更都是爲了知足業務需求的變更和實際狀況而產生的。

沒錯，任何不以業務爲基礎的框架, 都是耍流氓...

---

寫得很差, 歡迎拍磚!

喜歡能夠關注公衆號: 終身幼稚園