近來，幾乎人人都在談論微服務。微服務之所以火熱也是因為相對之前的應用開發(fā)方式有很多優(yōu)點，如更靈活、更能適應現(xiàn)在需求快速變更的大環(huán)境等。本文將介紹微服務架構設計中的一些要點。

創(chuàng)新互聯(lián)公司2013年成立，先為烏拉特后等服務建站，烏拉特后等地企業(yè)，進行企業(yè)商務咨詢服務。為烏拉特后企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。

微服務架構設計時有哪些要點呢？先看下圖是 Spring Cloud 的整個生態(tài)。

下圖是***實現(xiàn)微服務的十二原則：

接下來，細說微服務架構設計中不得不知的十大要點。

負載均衡 + API 網(wǎng)關

在實施微服務的過程中，不免要面臨服務的聚合與拆分。

當后端服務的拆分相對比較頻繁的時候，作為手機 App 來講，往往需要一個統(tǒng)一的入口，將不同的請求路由到不同的服務，無論后面如何拆分與聚合，對于手機端來講都是透明的。

有了 API 網(wǎng)關以后，簡單的數(shù)據(jù)聚合可以在網(wǎng)關層完成，這樣就不用在手機 App 端完成，從而手機 App 耗電量較小，用戶體驗較好。

有了統(tǒng)一的 API 網(wǎng)關，還可以進行統(tǒng)一的認證和鑒權，盡管服務之間的相互調用比較復雜，接口也會比較多。

API 網(wǎng)關往往只暴露必須的對外接口，并且對接口進行統(tǒng)一的認證和鑒權，使得內部的服務相互訪問的時候，不用再進行認證和鑒權，效率會比較高。

有了統(tǒng)一的 API 網(wǎng)關，可以在這一層設定一定的策略，進行 A/B 測試，藍綠發(fā)布，預發(fā)環(huán)境導流等等。

API 網(wǎng)關往往是無狀態(tài)的，可以橫向擴展，從而不會成為性能瓶頸。

無狀態(tài)化與獨立有狀態(tài)集群

x`

影響應用遷移和橫向擴展的重要因素就是應用的狀態(tài)。無狀態(tài)服務，是要把這個狀態(tài)往外移，將 Session 數(shù)據(jù)，文件數(shù)據(jù)，結構化數(shù)據(jù)保存在后端統(tǒng)一的存儲中，從而應用僅僅包含商務邏輯。

狀態(tài)是不可避免的，例如 ZooKeeper，DB，Cache 等，把這些所有有狀態(tài)的東西收斂在一個非常集中的集群里面。

整個業(yè)務就分兩部分，一個是無狀態(tài)的部分，一個是有狀態(tài)的部分。

無狀態(tài)的部分能實現(xiàn)兩點：

• 跨機房隨意地部署，也即遷移性。
• 彈性伸縮，很容易地進行擴容。

有狀態(tài)的部分，如 ZooKeeper，DB，Cache 有自己的高可用機制，要利用到它們自己高可用的機制來實現(xiàn)這個狀態(tài)的集群。

雖說無狀態(tài)化，但是當前處理的數(shù)據(jù)，還是會在內存里面的，當前的進程掛掉數(shù)據(jù)，肯定也是有一部分丟失的。

為了實現(xiàn)這一點，服務要有重試的機制，接口要有冪等的機制，通過服務發(fā)現(xiàn)機制，重新調用一次后端服務的另一個實例就可以了。

數(shù)據(jù)庫的橫向擴展

數(shù)據(jù)庫是保存狀態(tài)，是最重要的也是最容易出現(xiàn)瓶頸的。有了分布式數(shù)據(jù)庫可以使數(shù)據(jù)庫的性能隨著節(jié)點增加線性地增加。

分布式數(shù)據(jù)庫最最下面是 RDS，是主備的，通過 MySQL 的內核開發(fā)能力，我們能夠實現(xiàn)主備切換數(shù)據(jù)零丟失。

所以數(shù)據(jù)落在這個 RDS 里面，是非常放心的，哪怕是掛了一個節(jié)點，切換完了以后，你的數(shù)據(jù)也是不會丟的。

再往上就是橫向怎么承載大的吞吐量的問題，上面有一個負載均衡 NLB，用  LVS，HAProxy，Keepalived，下面接了一層 Query Server。

Query Server 是可以根據(jù)監(jiān)控數(shù)據(jù)進行橫向擴展的，如果出現(xiàn)了故障，可以隨時進行替換的修復，對于業(yè)務層是沒有任何感知的。

另外一個就是雙機房的部署，DDB 開發(fā)了一個數(shù)據(jù)運河 NDC 的組件，可以使得不同的 DDB 之間在不同的機房里面進行同步。

這時候不但在一個數(shù)據(jù)中心里面是分布式的，在多個數(shù)據(jù)中心里面也會有一個類似雙活的一個備份，高可用性有非常好的保證。

緩存

在高并發(fā)場景下緩存是非常重要的。要有層次的緩存，使得數(shù)據(jù)盡量靠近用戶。數(shù)據(jù)越靠近用戶能承載的并發(fā)量也越大，響應時間越短。

在手機客戶端 App 上就應該有一層緩存，不是所有的數(shù)據(jù)都每時每刻從后端拿，而是只拿重要的，關鍵的，時常變化的數(shù)據(jù)。

尤其對于靜態(tài)數(shù)據(jù)，可以過一段時間去取一次，而且也沒必要到數(shù)據(jù)中心去取，可以通過 CDN，將數(shù)據(jù)緩存在距離客戶端最近的節(jié)點上，進行就近下載。

有時候 CDN 里面沒有，還是要回到數(shù)據(jù)中心去下載，稱為回源，在數(shù)據(jù)中心的最外層，我們稱為接入層，可以設置一層緩存，將大部分的請求攔截，從而不會對后臺的數(shù)據(jù)庫造成壓力。

如果是動態(tài)數(shù)據(jù)，還是需要訪問應用，通過應用中的商務邏輯生成，或者去數(shù)據(jù)庫讀取，為了減輕數(shù)據(jù)庫的壓力，應用可以使用本地的緩存，也可以使用分布式緩存。

如 Memcached 或者 Redis，使得大部分請求讀取緩存即可，不必訪問數(shù)據(jù)庫。

當然動態(tài)數(shù)據(jù)還可以做一定的靜態(tài)化，也即降級成靜態(tài)數(shù)據(jù)，從而減少后端的壓力。

服務拆分與服務發(fā)現(xiàn)

當系統(tǒng)扛不住，應用變化快的時候，往往要考慮將比較大的服務拆分為一系列小的服務。

這樣***個好處就是開發(fā)比較獨立，當非常多的人在維護同一個代碼倉庫的時候，往往對代碼的修改就會相互影響。

常常會出現(xiàn)我沒改什么測試就不通過了，而且代碼提交的時候，經(jīng)常會出現(xiàn)沖突，需要進行代碼合并，大大降低了開發(fā)的效率。

另一個好處就是上線獨立，物流模塊對接了一家新的快遞公司，需要連同下單一起上線，這是非常不合理的行為。

我沒改還要我重啟，我沒改還讓我發(fā)布，我沒改還要我開會，都是應該拆分的時機。

再就是高并發(fā)時段的擴容，往往只有最關鍵的下單和支付流程是核心，只要將關鍵的交易鏈路進行擴容即可，如果這時候附帶很多其他的服務，擴容既是不經(jīng)濟的，也是很有風險的。

另外的容災和降級，在大促的時候，可能需要犧牲一部分的邊角功能，但是如果所有的代碼耦合在一起，很難將邊角的部分功能進行降級。

當然拆分完畢以后，應用之間的關系就更加復雜了，因而需要服務發(fā)現(xiàn)的機制，來管理應用相互的關系，實現(xiàn)自動的修復，自動的關聯(lián)，自動的負載均衡，自動的容錯切換。

服務編排與彈性伸縮

當服務拆分了，進程就會非常的多，因而需要服務編排來管理服務之間的依賴關系，以及將服務的部署代碼化，也就是我們常說的基礎設施即代碼。

這樣對于服務的發(fā)布，更新，回滾，擴容，縮容，都可以通過修改編排文件來實現(xiàn)，從而增加了可追溯性，易管理性，和自動化的能力。

既然編排文件也可以用代碼倉庫進行管理，就可以實現(xiàn)一百個服務中，更新其中五個服務，只要修改編排文件中的五個服務的配置就可以。

當編排文件提交的時候，代碼倉庫自動觸發(fā)自動部署升級腳本，從而更新線上的環(huán)境。

當發(fā)現(xiàn)新的環(huán)境有問題時，當然希望將這五個服務原子性地回滾，如果沒有編排文件，需要人工記錄這次升級了哪五個服務。

有了編排文件，只要在代碼倉庫里面 Revert，就回滾到上一個版本了。所有的操作在代碼倉庫里都是可以看到的。

統(tǒng)一配置中心

服務拆分以后，服務的數(shù)量非常多，如果所有的配置都以配置文件的方式放在應用本地的話，非常難以管理。

可以想象當有幾百上千個進程中有一個配置出現(xiàn)了問題，是很難將它找出來的，因而需要有統(tǒng)一的配置中心，來管理所有的配置，進行統(tǒng)一的配置下發(fā)。

在微服務中，配置往往分為以下幾類：

• 一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面。
• 第二類是啟動時就會確定的配置，這種配置往往通過環(huán)境變量，在容器啟動的時候傳進去。
• 第三類就是統(tǒng)一的配置，需要通過配置中心進行下發(fā)。例如在大促的情況下，有些功能需要降級，哪些功能可以降級，哪些功能不能降級，都可以在配置文件中統(tǒng)一配置。

統(tǒng)一日志中心

同樣是進程數(shù)目非常多的時候，很難對成千上百個容器，一個一個登錄進去查看日志，所以需要統(tǒng)一的日志中心來收集日志。

為了使收集到的日志容易分析，對于日志的規(guī)范，需要有一定的要求，當所有的服務都遵守統(tǒng)一的日志規(guī)范的時候，在日志中心就可以對一個交易流程進行統(tǒng)一的追溯。

例如在***的日志搜索引擎中，搜索交易號，就能夠看到在哪個過程出現(xiàn)了錯誤或者異常。

熔斷，限流，降級

服務要有熔斷，限流，降級的能力，當一個服務調用另一個服務，出現(xiàn)超時的時候，應及時返回，而非阻塞在那個地方，從而影響其他用戶的交易，可以返回默認的托底數(shù)據(jù)。

當一個服務發(fā)現(xiàn)被調用的服務，因為過于繁忙，線程池滿，連接池滿，或者總是出錯，則應該及時熔斷，防止因為下一個服務的錯誤或繁忙，導致本服務的不正常，從而逐漸往前傳導，導致整個應用的雪崩。

當發(fā)現(xiàn)整個系統(tǒng)的確負載過高的時候，可以選擇降級某些功能或某些調用，保證最重要的交易流程的通過，以及最重要的資源全部用于保證最核心的流程。

還有一種手段就是限流，當既設置了熔斷策略，又設置了降級策略，通過全鏈路的壓力測試，應該能夠知道整個系統(tǒng)的支撐能力。

因而就需要制定限流策略，保證系統(tǒng)在測試過的支撐能力范圍內進行服務，超出支撐能力范圍的，可拒絕服務。

當你下單的時候，系統(tǒng)彈出對話框說 “系統(tǒng)忙，請重試”，并不代表系統(tǒng)掛了，而是說明系統(tǒng)是正常工作的，只不過限流策略起到了作用。

全方位的監(jiān)控

當系統(tǒng)非常復雜的時候，要有統(tǒng)一的監(jiān)控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪里。

當系統(tǒng)出現(xiàn)異常的時候，監(jiān)控系統(tǒng)可以配合告警系統(tǒng)，及時地發(fā)現(xiàn)，通知，干預，從而保障系統(tǒng)的順利運行。

當壓力測試的時候，往往會遭遇瓶頸，也需要有全方位的監(jiān)控來找出瓶頸點，同時能夠保留現(xiàn)場，從而可以追溯和分析，進行全方位的優(yōu)化。

作者：劉超

簡介：畢業(yè)于上海交通大學，15 年云計算領域研發(fā)及架構經(jīng)驗，先后在 EMC，CCTV 證券資訊頻道，HP，華為，網(wǎng)易從事云計算和大數(shù)據(jù)架構工作。

文章標題：你必須了解的微服務架構設計的10個要點！
網(wǎng)址分享：http://uogjgqi.cn/article/cdchesh.html