學習本文前，請確保你了解并搭建過至少一個簡單的微服務(wù)應(yīng)用。對微服務(wù)的設(shè)計理念及編程思想有一定的了解匕争。
當我們需要自己從零開始設(shè)計或搭建微服務(wù)項目的時候捅厂，由于缺乏經(jīng)驗及高人指點贯卦，心中難免有些惶恐。我們要如何去搭建我們的微服務(wù)項目焙贷？如果不能一步到位的話撵割，我們該如何逐步去實施？微服務(wù)系統(tǒng)會存在哪些常見問題辙芍？有哪些風險點需要去關(guān)注啡彬？微服務(wù)的邊界在哪里，哪些東西可以用微服務(wù)來實現(xiàn)故硅，哪些不能庶灿？
那么本文講從易到難、從淺到深吃衅、逐步實現(xiàn)從實用到四高的相關(guān)技術(shù)梳理(高可能往踢、高性能、高并發(fā)徘层、高智能)峻呕。讓你在微服務(wù)項目的各個階段都能夠不慌不忙，胸有成竹的構(gòu)建及完善我們的微服務(wù)項目
1.微服務(wù)最少組件
當我們對微服務(wù)的四高沒什么要求的時候惑灵，僅僅是想將項目拆分成多個團隊并行開發(fā)山上，那我們要如何去搭建我們的微服務(wù)項目呢?
以dubbo微服務(wù)框架為例:
我們至少需要有api網(wǎng)關(guān)、zk英支、provider佩憾、consumer
2.微服務(wù)編排
當我們對微服務(wù)項目進行拆分的時候，該如何下手，怎么拆分才是正確的? 有沒有統(tǒng)一的標準妄帘？
目前業(yè)內(nèi)對微服務(wù)的拆分并沒有統(tǒng)一的規(guī)范及標準楞黄，拆分的時候必須根據(jù)具體的業(yè)務(wù)及開發(fā)團隊現(xiàn)狀來確定。下面我們以一個旅游微服務(wù)系統(tǒng)平臺實例來進行說明：
從上圖我們不難看出一些基本的編排規(guī)則：
- 微服務(wù)不能交叉調(diào)用抡驼，否則上線的時候可能會出現(xiàn)服務(wù)不可用的問題
- 微服務(wù)可以是獨立的鬼廓、不依賴其他任何服務(wù)的
- 微服務(wù)必須進行分層，低層級的不能調(diào)用高層級的微服務(wù)
- 微服務(wù)的交互方式致盟，必須提前設(shè)計好碎税，是同步還是異步？
比如: 消息通知最好用MQ異步來實現(xiàn)馏锡，否則會影響諸如訂單主流程的運行
3.微服務(wù)排障
當我們在線運行的微服務(wù)項目頻繁出現(xiàn)Bug雷蹂，又無法快速準確的定位的時候，我們需要對微服務(wù)項目進行哪些升級改造杯道？
以Dubbo微服務(wù)框架為例匪煌，常見的使用zipkin來進行調(diào)用鏈的跟蹤：
在zipkin的圖形管理界面上，很容易能看到調(diào)用鏈故障環(huán)境
ELK日志系統(tǒng)通過對日志的監(jiān)控及分析党巾，也可以幫我們快速定位故障
4.微服務(wù)的高并發(fā)
當微服務(wù)項目在線運營一段時間后萎庭，總會迎來流量的高峰，那我們應(yīng)該提前做好哪些準備來應(yīng)對高并發(fā)的用戶場景呢齿拂？
- 利用Nginx進行前后端分離驳规，請靜態(tài)資源部署在NG上
- 接入云存儲，把圖片署海、視頻达舒、app安裝包等發(fā)布到云存儲上
- 把云存儲、靜態(tài)資源全部接入CDN叹侄，并做好相應(yīng)的策略
- 充分利用Redis等緩存層，減輕數(shù)據(jù)庫的壓力
5.微服務(wù)高可用
當個別微服務(wù)偶爾出現(xiàn)問題影響用戶體驗的時候昨登，比如偶爾用戶無法下單趾代、無法支付，又或者我們需要頻繁升級的時候丰辣，我們應(yīng)該采取什么樣的措施撒强？
- 負載比較高的服務(wù)，相同的開啟多個
- 上線發(fā)布的時候笙什，采用灰度發(fā)布的方式
- 打開錯誤重試機制飘哨，dubbo默認重試3次
6.微服務(wù)的高性能
當一個項目用戶越來越多、業(yè)務(wù)越來越復(fù)雜琐凭、我們該如何保證在復(fù)雜的業(yè)務(wù)場景下芽隆，實現(xiàn)對用戶請求的快速響應(yīng)？
- 數(shù)據(jù)庫開啟一主多從，把查詢量大的微服務(wù)單獨分配到從庫上
- 利用Mycat等服務(wù)中間件胚吁，實現(xiàn)對數(shù)據(jù)庫主從自動切換
- 利用MapReduce算法牙躺，都任務(wù)進行分片處理，統(tǒng)一結(jié)果匯總
- 利用多庫進行數(shù)據(jù)庫水平拆分腕扶，也就是我們常說的分庫分表
- 把查詢量大的服務(wù)采用NoSQL數(shù)據(jù)庫(例如：ES)進行部署
7.微服務(wù)的分布式事務(wù)
當多個微服務(wù)同時處理一個用戶請求的時候孽拷，比如用戶下單需要同時調(diào)用權(quán)限系統(tǒng)、商品管理系統(tǒng)半抱、進銷存系統(tǒng)脓恕、支付系統(tǒng)等微服務(wù)，如果保證數(shù)據(jù)的一致性窿侈？而且失敗的時候還必須同時回滾炼幔？
常見的分布式事務(wù)有2種
- 補償機制，利用定時任務(wù)檢查數(shù)據(jù)是否需要回滾
- 強事務(wù)棉磨，利用mysql的xa事務(wù)(也可以使用各種中間件：比如阿里的FESCAR)
#mysql實現(xiàn)XA事務(wù)的SQL語句
XA START 'xatestx','XXXXXXXXXXXXXXXXXXXXXXXX';
INSERT INTO suoron_test (id,name) VALUES(21,'試試');
XA END 'xatestx';
XA PREPARE 'xatestx';
#大家都準備好了江掩，一塊提交
XA COMMIT 'xatestx';
XA ROLLBACK 'xatestx';
XA RECOVER;
8.微服務(wù)服務(wù)治理
當我們團隊越來越大的時候，我們需要把系統(tǒng)交付給運維的兄弟進行維護乘瓤，我們該如何幫忙他們制定專門的運維管理的規(guī)則环形？
常見的服務(wù)治理框架有：
- Dubbo的Admin -- 服務(wù)管理
- Spring cloud 的hystrix -- 熔斷
- zabbix -- 微服務(wù)監(jiān)控及巡檢
- apollo -- 攜程配置管理(后期服務(wù)器配置全由運維負責)
9.微服務(wù)的高智能
當系統(tǒng)出現(xiàn)問題，或者資源不夠的時候衙傀，每次需要手工去維護顯然不現(xiàn)實抬吟，人工處理的響應(yīng)速度太慢，恢復(fù)一個故障可能需要長達幾個小時的時間统抬，那我們該如何實行系統(tǒng)的智能運行火本？
必須充分利用容器集群及容器調(diào)度系統(tǒng)（例如：Kubernetes）
比如：微服務(wù)出現(xiàn)嚴重故障時，容器能夠自動重啟
當請求流量增大的時候自動開啟新的微服務(wù)
當流量減少時聪建，自動釋放資源钙畔，用于資源消耗嚴重的報表統(tǒng)計等
