企業應用架構的發展演進

時間 2019-11-12

原文原文鏈接

前言

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

框架的演進

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 理論的實踐，微服務架構愈來愈被重視與應用。

可是成熟的企業,已有成熟的架構, 徹底不必冒風險進行微服務改造。

總的來講二者都有各自的優點, 具體如何使用, 則根據各個企業自身的考量。

總結：

　　簡單來講企業應用架構演變(不嚴謹的說)：從垂直架構模式(MVC)----->PRC架構模式------->到SOA模式-------->微服務。

　　垂直架構：早期客戶流量較少，全部的業務模塊都是存放在一個項目裏，部署配一臺服務器就能解決咱們的需求。

　　　　　　　　可是若是就這一臺服務器掛了，就不能再爲用戶提供服務，因此有了多臺服務器，以備不時之需。

　　　　　　　　可是雖然有備用的服務器，可歸根到底應用資源仍是都跑在一臺服務器中，這就形成了資源浪費，因此就加入了負載均衡，就是說不能就人一臺服務器幹活！！！大家剩下的服務器也要分單壓力，因而這樣既能不浪費資源，還安全有效的服務了客戶。

　 RPC架構：RPC（Remote Procedure Call）遠程過程調用。而PRC架構的引入，是爲了解決應用與應用之間的交互問題。當垂直應用愈來愈多，應用之間交互不可避免，將核心和公共業務抽取出來，做爲獨立的服務，實現先後臺邏輯分離。此時，用於提升業務複用及拆分的RPC框架是關鍵。他的底層是經過socket通訊和序列化反序列化實現的。

　　底層原理：http://www.javashuo.com/article/p-ygkjnhba-gr.html66

SOA架構：SOA架構的特色就是服務中心隨着業務發展，服務數量愈來愈多，服務生命週期管控和運行態的治理成爲瓶頸，此時用於提高服務質量的SOA服務治理是關鍵。

　特色:

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

　　例子：阿里巴巴的Dubbo框架

微服務：能夠獨立的部署、運行、升級，不只如此，這個系統架構還讓微服務與微服務之間在結構上「鬆耦合」，而在功能上則表現爲一個統一的總體。這種所謂的「統一的總體」表現出來的是統一風格的界面，統一的權限管理，統一的安全策略，統一的上線過程，統一的日誌和審計方法，統一的調度方式，統一的訪問入口等等。
　　 微服務的目的：是有效的拆分應用，實現敏捷開發和部署。
　　　　微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，緣由就是由於若是團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每一個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能下降。