1.系統架構演變

隨著互聯網的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。系統架構也因此不斷的演進、升級、迭代。從單一應用，到垂直拆分，到分布式服務，到SOA，以及現在火熱的微服務架構，還有在Google帶領下來勢洶涌的Service Mesh。我們到底是該乘坐微服務的船只駛向遠方，還是偏安一隅得過且過？

其實生活不止眼前的茍且，還有詩和遠方。所以我們今天就回顧歷史，看一看系統架構演變的歷程；把握現在，學習現在最火的技術架構；展望未來，爭取成為一名優秀的Java工程師。

1.1.集中式架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。此時，用于簡化增刪改查工作量的數據訪問框架(ORM)是影響項目開發的關鍵。

存在的問題：

• 代碼耦合，開發維護困難
• 無法針對不同模塊進行針對性優化
• 無法水平擴展
• 單點容錯率低，并發能力差

1.2.垂直拆分

當訪問量逐漸增大，單一應用無法滿足需求，此時為了應對更高的并發和業務需求，我們根據業務功能對系統進行拆分：

優點：

• 系統拆分實現了流量分擔，解決了并發問題
• 可以針對不同模塊進行優化
• 方便水平擴展，負載均衡，容錯率提高

缺點：

• 系統間相互獨立，會有很多重復開發工作，影響開發效率

1.3.分布式服務

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用于提高業務復用及整合的分布式調用是關鍵。

優點：

• 將基礎服務進行了抽取，系統間相互調用，提高了代碼復用和開發效率

缺點：

• 系統間耦合度變高，調用關系錯綜復雜，難以維護

1.4.流動計算架構（SOA）

SOA ：面向服務的架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率。此時，用于提高機器利用率的資源調度和治理中心(SOA)是關鍵

以前出現了什么問題？

• 服務越來越多，需要管理每個服務的地址
• 調用關系錯綜復雜，難以理清依賴關系
• 服務過多，服務狀態難以管理，無法根據服務情況動態管理

服務治理要做什么？

• 服務注冊中心，實現服務自動注冊和發現，無需人為記錄服務地址
• 服務自動訂閱，服務列表自動推送，服務調用透明化，無需關心依賴關系
• 動態監控服務狀態監控報告，人為控制服務狀態

缺點：

• 服務間會有依賴關系，一旦某個環節出錯會影響較大
• 服務關系復雜，運維、測試部署困難，不符合DevOps思想

1.5.微服務

前面說的SOA，英文翻譯過來是面向服務。微服務，似乎也是服務，都是對系統進行拆分。因此兩者非常容易混淆，但其實卻有一些差別：

微服務的特點：

• 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責
• 微：微服務的服務拆分粒度很小，例如一個用戶管理就可以作為一個服務。每個服務雖小，但“五臟俱全”。
• 面向服務：面向服務是說每個服務都要對外暴露Rest風格服務接口API。并不關心服務的技術實現，做到與平臺和語言無關，也不限定用什么技術實現，只要提供Rest的接口即可。
• 自治：自治是說服務間互相獨立，互不干擾
  • 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多。
  • 技術獨立：因為是面向服務，提供Rest接口，使用什么技術沒有別人干涉
  • 前后端分離：采用前后端分離開發，提供統一Rest接口，后端不用再為PC、移動段開發不同接口
  • 數據庫分離：每個服務都使用自己的數據源
  • 部署獨立，服務間雖然有調用，但要做到服務重啟不影響其它服務。有利于持續集成和持續交付。每個服務都是獨立的組件，可復用，可替換，降低耦合，易維護

2.服務調用方式

2.1.RPC和HTTP

無論是微服務還是SOA，都面臨著服務間的遠程調用。那么服務間的遠程調用方式有哪些呢？

常見的遠程調用方式有以下2種：

• RPC：Remote Produce Call遠程過程調用，類似的還有RMI。自定義數據格式，基于原生TCP通信，速度快，效率高。早期的webservice，現在熱門的dubbo，都是RPC的典型代表（dubbo是阿里開源的java框架，2012年停更過一段時間，2017年又繼續維護）

• Http：http其實是一種網絡傳輸協議，基于TCP，規定了數據傳輸的格式。現在客戶端瀏覽器與服務端通信基本都是采用Http協議，也可以用來進行遠程服務調用。缺點是消息封裝臃腫，優勢是對服務的提供和調用方沒有任何技術限定，自由靈活，更符合微服務理念。

  現在熱門的Rest風格，就可以通過http協議來實現。

如果你們公司全部采用Java技術棧，那么使用Dubbo作為微服務架構是一個不錯的選擇。

相反，如果公司的技術棧多樣化，而且你更青睞Spring家族，那么SpringCloud搭建微服務是不二之選。在我們的項目中，我們會選擇SpringCloud套件，因此我們會使用Http方式來實現服務間調用。

網絡傳輸7層協議

2.2.Http客戶端工具

既然微服務選擇了Http，那么我們就需要考慮自己來實現對請求和響應的處理。不過開源世界已經有很多的http客戶端工具，能夠幫助我們做這些事情，例如：

• HttpClient
• OKHttp
• URLConnection

接下來，不過這些不同的客戶端，API各不相同

2.3.Spring的RestTemplate

Spring提供了一個RestTemplate模板工具類，對基于Http的客戶端進行了封裝，并且實現了對象與json的序列化和反序列化，非常方便。RestTemplate并沒有限定Http的客戶端類型，而是進行了抽象，目前常用的3種都有支持：

• HttpClient
• OkHttp
• JDK原生的URLConnection（默認的）

首先在項目中注冊一個RestTemplate對象，可以在啟動類位置注冊：

@SpringBootApplication
public class HttpDemoApplication {public static void main(String[] args) {SpringApplication.run(HttpDemoApplication.class, args);}@Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}

在測試類中直接@Autowired注入：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = HttpDemoApplication.class)
public class HttpDemoApplicationTests {@Autowiredprivate RestTemplate restTemplate;@Testpublic void httpGet() {// 調用springboot案例中的rest接口User user = this.restTemplate.getForObject("http://localhost/user/1", User.class);System.out.println(user);}
}

• 通過RestTemplate的getForObject()方法，傳遞url地址及實體類的字節碼，RestTemplate會自動發起請求，接收響應，并且幫我們對響應結果進行反序列化。

學習完了Http客戶端工具，接下來就可以正式學習微服務了。