前言
從計算機誕生到現在其實也就短短幾十年, 從最早的軍事使用,到投入商業, 直至現在走入尋常百姓家中。用日新月異來形容毫不為過。 企業的服務框架, 也隨着計算機的發展, 層層迭代, 由最早的單一型應用服務發展至現在滿足於幾億甚至幾十億的人民的大型服務
框架的演進
一、垂直型服務
單一型應用
早期, 企業的對外提供的服務比較單一, 客戶流量也相對不足。 因此將所有的模塊，代碼打包在一個項目中，集中部署一台機器上。
這樣操作簡單粗暴，運維人員只要關注這一台服務器就了事了。
但是問題來了, 如果服務器宕機了怎么辦呢, 這不就意味着無法對外提供服務了嗎?
主備機應用
為解決上述問題, 倒也簡單, 給每台機器增加幾台備機不就行了嗎？
服務器掛掉了， 快速切換服務器，依舊能及時滿足對外服務。
可是問題又來了, 企業是在快速發展的啊。
企業的客戶會越來越多, 流量越來越大, 單單一台服務器對外提供服務， 哪里撐得住啊， 不分分鍾被搞掛掉才怪。
多機服務 + 負載均衡
於是乎， 我們多增加幾台服務器，通過負載均衡器（F5或者NGINX等）將客戶請求（按負載均衡算法）合理的分配到各台機器上， 讓各台機器同時提供對外服務。
這樣每台服務的器壓力降低了， 能快速和安全的服務於客戶了。
現在, 由於我們提供的服務讓客戶非常滿意, 公司賺錢了, 開始要拓展業務了, 不再是之前的單一服務了, 我們要做大做強。
於是我們需要瘋狂開發新模塊, 對外提供更多的優質服務。
那么問題來了， 那么多模塊， 我們總不能還是那么簡單粗暴的擠在單一應用上吧。
開發人員還怎么愉快的合作了? 代碼合並的時候，還不分分鍾掀桌子?
而且，每台機器的算力畢竟有限， 所有模塊集中在同一個應用上，不是很不合理嗎?
因此，我們需要把幾個模塊獨立出去， 形成新的服務。
當服務於服務之間存在依賴時， 再讓兩者進行交互， 完成數據傳遞。
那服務間怎么交互呢？ 這就要說說RPC了。
二、RPC服務
什么是RPC
RPC（Remote Procedure Call）—遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。
RPC使用
有了RPC 服務間就能愉快的進行數據傳遞了。
我們的架構就能得到很好的改良了。
現在我們的框架分成了很多獨立的小模塊,模塊間能實時的,有效的進行消息傳遞。
並且業務與業務間得到很好的解耦， 機器的算力也不必再擔心支撐不起系統了。看起來很完美。
可是，運營人員不干了: 現在服務那么分散， 機器那么多，讓我怎么管理？ 哪天哪台服務掛掉了， 讓我上哪找去？
因此， 我們需要將我們的所有服務有效的管理起來。
三、SOA
什么是SOA
面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，並通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立於實現服務的硬件平台、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
阿里巴巴的Dubbo就是一個非常好的服務治理框架, 有興趣的朋友可以去學習學習。
SOA的使用
通過SAO的服務治理方案, 我們將我們的框架進行終極改良。
- 將所有的服務提供者注冊到注冊中心。
- 客戶端向注冊中心訂閱服務
- 注冊中心向客戶端推送有效的服務信息
- 客戶端得到所有可調用服務的信息后， 根據需求，按負載均衡算法， 進行調用， 獲取數據。
我們將每次調用情況都記錄在服務監控組件上，這樣服務的調用情況，健康狀況就一目了然了。
更甚者，我們可以獨立一個配置中心模塊，如需要修改服務的配置信息時， 通過此模塊實時推送配置信息到所有或者指定的機器上，進行動態修改。 運營人員再也不用一台機器一台機器的修改配置信息了。
至此， 我們的框架可以有效的滿足不斷擴張的業務需求以及保證機器的平穩運行了。 到這里, 框架可以算是暫時定型了, 短期內, 不會再做什么大規模的改造了。
到這里就結束了嗎?那接下來的微服務又是什么呢, 還有必要升級嗎?
四、微服務
什么是微服務
微服務架構的系統是一個分布式的系統,每個微服務基本是一個能獨立發布的應用服務，因此可以作為獨立組件升級、灰度或復用等，對整個大應用的影響也較小，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發，甚至整個團隊的組織架構也會更精簡，因此溝通成本低、效率高。
說的微服務, SpringCloud是繞不開的話題, 有興趣的朋友可以去學習學習。
微服務和SOA的差異
SOA和微服務一脈相承, 都是面向服務的治理方案
- 微服務顆粒度更細, 一個系統拆成多個服務, SOA顆粒度更大
- 微服務功能獨立, 獨立部署; SOA單體架構,業務耦合
- 微服務服務自治, 松散管理; SOA集中式管理
隨着敏捷開發、虛擬化技術、DevOps 理論的實踐，微服務架構越來越被重視與應用。
但是成熟的企業,已有成熟的架構, 完全沒必要冒風險進行微服務改造。
總的來說兩者都有各自的優勢, 具體如何使用, 則根據各個企業自身的考量。
總結：
簡單來說企業應用架構演變(不嚴謹的說)：從垂直架構模式(MVC)----->PRC架構模式------->到SOA模式-------->微服務。
垂直架構：早期客戶流量較少，所有的業務模塊都是存放在一個項目里，部署配一台服務器就能解決我們的需求。
但是如果就這一台服務器掛了，就不能再為用戶提供服務，所以有了多台服務器，以備不時之需。
但是雖然有備用的服務器，可歸根到底應用資源還是都跑在一台服務器中，這就造成了資源浪費，所以就加入了負載均衡，就是說不能就人一台服務器干活！！！你們剩下的服務器也要分單壓力，於是這樣既能不浪費資源，還安全有效的服務了客戶。
RPC架構：RPC（Remote Procedure Call）遠程過程調用。而PRC架構的引入，是為了解決應用與應用之間的交互問題。當垂直應用越來越多，應用之間交互不可避免，將核心和公共業務抽取出來，作為獨立的服務，實現前后台邏輯分離。此時，用於提高業務復用及拆分的RPC框架是關鍵。他的底層是通過socket通信和序列化反序列化實現的。
底層原理：https://www.cnblogs.com/huangqingshi/p/7803642.html66
SOA架構：SOA架構的特點就是服務中心 隨着業務發展，服務數量越來越多，服務生命周期管控和運行態的治理成為瓶頸，此時用於提升服務質量的SOA服務治理是關鍵。
特點:
- 將所有的服務提供者注冊到注冊中心。
- 客戶端向注冊中心訂閱服務
- 注冊中心向客戶端推送有效的服務信息
- 客戶端得到所有可調用服務的信息后， 根據需求，按負載均衡算法， 進行調用， 獲取數據。
例子：阿里巴巴的Dubbo框架
微服務：可以獨立的部署、運行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“松耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的界面，統一的權限管理，統一的安全策略，統一的上線過程，統一的日志和審計方法，統一的調度方式，統一的訪問入口等等。
微服務的目的：是有效的拆分應用，實現敏捷開發和部署 。
微服務提倡的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。