文章目錄
- 1、系統架構的開發演變
- 1.1 集中式架構
- 1.2 垂直拆分
- 1.3 分布式服務
- 1.4 服務治理
- 1.5 微服務
- 2、遠程呼叫方式
- 2.1 RPC
- 2.2 HTTP
- 總結
學習到Spring Cloud這部分的內容，才發現慢慢的，我已經稍微接近了架構的范疇，或者本身學習spring框架本身，就是屬于進入了架構的內容，今天為了總結關于系統架構開發，特意做的小筆記，
1、系統架構的開發演變
計算機技術就是隨著互聯網的發展而發展起來，包括系統架構也是如此不斷地升級迭代，
1.1 集中式架構
在一開始網站流量很小的時候，只需要一個應用就可以將所有的功能部署在一起以減少部署的節點個數和方便管理的成本，
額，比如說我的個人的記賬或者是個人的博客系統開發應該就是典型的集中式架構了，這里舉一個大家都會選擇做的商品購物網站系統，(補充：最下面是資料庫的模型圖)
首先優點就是系統開發很快，維護成本降低并且適用于要求低的系統，
當然缺點明顯：
集中式管理對于專案的耦合度過高，后期維護比較困難，
無法針對不同的模塊進行優化，
無法進行水平的擴展—即專案某個功能的優化
并發能力較差
1.2 垂直拆分
然后漸漸地，你的個人博客或者個人商品管理系統訪問量逐漸增大，這個時候為了應對更高的并發和業務要求，就要根據業務功能對系統進行拆分，
具體開發估計也不一定會像我這樣的內容拆分進行垂直開發，不過相對于集中式架構很明顯我們是單獨的拎出來了，優點很明顯：
- 系統拆分實作流量的分擔，一定的解決了并發問題
- 可以針對不同的模塊進行優化
- 方便水平擴展，負載均衡
缺點在猶豫獨立性好像又相對集中式大大增強，這樣對于重復開發作業率就會大大增加，
1.3 分布式服務
當發現垂直應用越來越多，好像應用之間的互動就會不可避免了，并且每個模塊之間并沒有主次之分(比如說用戶可能更多會使用商品主要內容的瀏覽而非權限&用戶管理)，
這個時候就將核心業務抽取出來作為獨立的服務，形成整個專案中的服務中心，前端應用能夠更加快速的回應多變的市場需求，所以基于垂直拆分的缺陷，用于提高整合能力的分布式呼叫就是關鍵，
優點在于將基礎服務進行了抽取，使得系統間能夠相互呼叫提高了代碼復用和開發效率，缺點在于系統的呼叫錯綜復雜，變得難以維護，
1.4 服務治理
SOA服務治理就是面向服務的架構，這個時候就有這種類似微服務相關的概念了，
它是一種設計方法，其中包括多種服務，服務之間通過相互依賴最終提供一系列的功能，一個服務通常以獨立的形式存在于作業系統中，各個服務之間通過網路來呼叫，
這就有點像騰訊集“QQ音樂、酷狗和酷我音樂”組成的騰訊音樂市場一樣，騰訊通過購買并獲得的音樂著作權通過連接服務，就可以在這三家音樂軟體進行使用，個人形象理解如有誤請諒解，
ESB就像是一根管道，用來里連接各個服務節點，為了集成不同系統，不同協議的服務，即做了訊息的轉化解釋和路有作業讓不同的服務互聯互通，
SOA的缺點：每個供應商提供的ESB產品有偏差，自身實作較為復雜；ESB集成整合所有服務和協議、資料轉換使得運維、測驗部署困難，所有服務都通過一個通路通信，直接降低了通信速度，
1.5 微服務
微服務架構是使用一套小服務來開發單個應用的方式或者途徑，每個服務基于單一業務能力構建，運行在自己的行程中，并使用輕量級通信——HTTP、API，通過自動化部署機制來獨立部署，
這些服務可以使用不同的 編程語言實作，以及不同資料存盤技術，并保持最低限度的集中式管理，
API Gateway網關是一個服務器，是系統的唯一入口，網關提供RESTful/HTTP的方式訪問服務，而服務端通過服務注冊中心進行服務注冊和管理，
微服務特點：
單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
面向服務：面向服務是說每個服務都要對外暴露服務介面API，并不關心服務的技術實作，做到與平臺和語言無關，也不限定用什么技術實作，只要提供REST的介面即可，
自治：自治是說服務間互相獨立，互不干擾
- 團隊獨立：每個服務都是一個獨立的開發團隊，
- 技術獨立：因為是面向服務，提供REST介面，使用什么技術沒有別人干涉
- 前后端分離：采用前后端分離開發，提供統一REST介面，后端不用再為PC、移動段開發不同介面
- 資料庫分離：每個服務都使用自己的資料源
2、遠程呼叫方式
對于面向服務的架構，SOA和微服務都是面臨著服務的遠程呼叫，接下來就說一下遠程呼叫方式，
常見的遠程呼叫方式有以下幾種：
- RPC：Remote Procedure Call遠程程序呼叫，類似的還有RMI，自定義資料格式，基于原生TCP通信，速度快，效率高，早期的Web Service，現在熱門的Dubbo，都是RPC的典型，
- HTTP：HTTP其實是一種網路傳輸協議，基于TCP，規定了資料傳輸的格式，現在客戶端瀏覽器與服務端通信基本都是采用HTTP協議，也可以用來進行遠程服務呼叫，缺點是訊息封裝臃腫，現在熱門的REST風格，就可以通過HTTP協議來實作，
這兩個方式并沒有哪一個好或者不好，當然要看具體情況具體分析，
2.1 RPC
RPC是一個計算機通信協議， 該協議允許運行于一臺計算機的程 序呼叫另一臺計算機的子程式，而程式員無需額外地為這個互動作用編程，說得通俗一點就是：A計算機提供一個服務，B計算機可以像呼叫本地服務那樣呼叫A計算機的服務，
RPC的機制是根據語言的API來定義的，而不是根據基于網路的應用來定義的，如果專案全部采用Java技術堆疊，那么使用Dubbo作為微服務架構是一個不錯的選擇，
2.2 HTTP
HTTP就更加熟悉了，它是一個網路傳輸協議，基于TCP，作業在應用層，規定了資料傳輸的格式，現在客戶端瀏覽器與服務端通 信基本都是采用HTTP協議，也可以用來進行遠程服務呼叫，
如果專案的技術堆疊多樣化，而且更青睞Spring家族，那么Spring Cloud搭建微服務是最好的選擇，會選擇 Spring Cloud套件，因此會使用HTTP方式來實作服務間呼叫，
總結
基于前面兩個內容的學習，已經很好的引出了spring cloud的概念，后續會對spring cloud的相關內容進行詳細的介紹，謝謝大家的閱讀，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/335507.html
標籤：其他