一、微服務的現狀及未來

1.服務架構的演變

1.1 單體架構

單體架構應該是我們最先接觸到的架構實現了，在單體架構中使用經典的三層模型，即表現層，業務邏輯層和數據訪問層。

單體架構只適合在應用初期，且訪問量比較小的情況下使用，優點是性價比很高，開發速度快，成本低，但缺點也很明顯，這時擴展的首先就是考慮服務器的集群處理。

1.2 集群

針對單個服務器在訪問量越來越大的情況越來越吃力的情況，我們可以考慮服務器的集群化處理。

集群的部署大大提高了服務的處理能力，同時利用Nginx提供的負載均衡機制，來分發請求，使用戶的體驗沒有改變。

1.3 垂直化

上面的集群部署是可以解決一部分的服務器壓力，但是隨著用戶訪問量的增多，集群節點增加到一定階段的時候，其實作用就已經不是太大了，因為將所有的業務都集中在一起，造成耦合度很高，這時我們可以考慮業務的拆分。來提高系統的性能。比如將原來在一個系統里面的業務拆分為用戶系統，訂單系統和商品系統。也就是我們講的垂直化拆分如下：

服務垂直化拆分后是可以大大地提高整體的服務處理能力，但是也會出現很多的冗余的代碼，比如用戶系統要操作訂單庫，要操作商品庫，訂單系統也有可能要操作用戶庫和商品庫等。

1.4 服務化

針對垂直化拆分出現的問題，這時就出現了我們經常聽到的SOA(面向服務的架構).什么是SOA呢？在《微服務設計》中有這么一段描述

SOA是一種設計方法，其中包括多個服務，而服務之間通過配合最終會提供一系列功能，一個服務通常以獨立的形式存在于操作系統進程中，服務之間通過網絡調用，而非采用進程內調用的方式進行通信。

業務重用，共享服務，

1.5 微服務化

在SOA的基礎上繼續演進就是我們講的微服務。SOA的服務更細粒度的拆分后就是微服務。根據時間遞進。

對基礎運維的要求能力會越來越高，虛擬化，容器化等。

微服務和SOA的區別：

1.思想上：微服務的目的是解耦而SOA的目的是實現數據的互通和共享性。

2.協議：微服務會使用一些輕量級的通信協議(Restful API)

3.基礎設施要求，微服務更加強調開發運維的持續交付。

2. 微服務架構的需求

2.1 RPC框架

在微服務架構中，服務與服務之間要實現接口的調用我們肯定要通過相關的RPC(Remote Procedure Call)框架來實現。

常用的RPC框架有:Dubbo,google的GRPC，Apache的Thrift，微博的Motan，京東的EasyRPC等。我們通過RPC框架可以去調用服務提供者提供的服務，但有一個前提是我們要能找到這個服務。通常我們的服務部署都是集群多節點的部署，所以在消費者這端就不可能直接寫死在代碼里面，這時就涉及到了服務的發現問題，這時就需要另一個組件注冊中心了

2.2 注冊中心

注冊中心實現服務地址管理的功能，解決服務動態感知(上線，下線)。

2.3 負載均衡

在服務注冊中心的介紹中我們可以看到負載均衡的應用。我們可以通過Ribbon來實現客戶端的負載均衡，負載均衡的策略可以是：輪詢，隨機，根據響應時間來計算權重的輪詢等。

2.4 配置中心

在微服務架構中我們有很多個服務，而每個服務中是都會有單獨的配置文件的。里面有很多的配置信息的有關聯的，而且對于后期的更新維護也會非常的不方便，這時配置中心就上場了。常用的配置中心有：
apollo/Nacos/disconf/zookeeper/diamond/Spring Cloud Config