微服務(wù)架構(gòu)相對于單體架構(gòu)有很大的變化，也產(chǎn)生了一些新的設(shè)計模式，比如 sidecar，如何開發(fā)一個微服務(wù)應(yīng)用是一件有很大挑戰(zhàn)性的事情，我們經(jīng)常會聽到有人討論如何劃分微服務(wù)，多細(xì)的顆粒度才是微服務(wù)等問題。初學(xué)者經(jīng)常會處于一個“忐忑不安”的狀態(tài)，所以我們急需要知道如何才能走上正確的微服務(wù)道路，或者需要一些最佳實踐指導(dǎo)我們?nèi)绾卧O(shè)計、開發(fā)一個微服務(wù)應(yīng)用。
1、不驕不躁不跟風(fēng) 知己知彼方可百戰(zhàn)不殆
雖然現(xiàn)在已經(jīng)進(jìn)入到一個不談微服務(wù)就落伍的時代，但作為 IT 從業(yè)者，我們一定要站在切身利益出發(fā)，多思考幾個“為什么”，不要急于跟風(fēng)。原因很簡單，不管外面如何風(fēng)吹雨打，只要你的房子足夠結(jié)實、安全、舒服，那一般情況下就不需要拆除重建，所以在決定繼續(xù)沿用單體架構(gòu)還是轉(zhuǎn)向微服務(wù)架構(gòu)之前，我們一定要做兩件事情：
第一件事，從外部了解兩種架構(gòu)各自的優(yōu)劣：
可以看到，單體應(yīng)用并不是一無是處。
第二件事，審視我們自己的業(yè)務(wù)：
- 上述單體架構(gòu)列出的一些問題是否已經(jīng)嚴(yán)重影響了我們的業(yè)務(wù)？
- 企業(yè)新的業(yè)務(wù)系統(tǒng)是否要滿足快速迭代、彈性等需求？
- 團(tuán)隊內(nèi)是否有 DevOps 氛圍？
- 企業(yè)內(nèi)是否有足夠的動力和技術(shù)儲備去接觸新的技術(shù)？
了解了單體應(yīng)用和微服務(wù)應(yīng)用的優(yōu)劣特點，分析了企業(yè)自身的業(yè)務(wù)訴求和實際情況，最終還是決定轉(zhuǎn)型微服務(wù)架構(gòu)，那么我們也要清楚這不是一朝一夕的事情，需要分階段逐步推進(jìn)。
2、蒙眼狂奔不可取 循序漸進(jìn)方可順利進(jìn)階
第一階段試煉—— 開發(fā)新應(yīng)用
對于初次接觸微服務(wù)的企業(yè)，選擇新應(yīng)用入手是正確的方式。
第一步可以選擇 web-scale、無狀態(tài)類型的新應(yīng)用上手，比如基于 nginx 的網(wǎng)站、文檔等，這類應(yīng)用非常簡單且容易實現(xiàn)，而且能體驗到微服務(wù)在容器平臺上的各種功能。
有了一定的經(jīng)驗之后，第二步就可以開發(fā)有狀態(tài)類型的新應(yīng)用，有狀態(tài)服務(wù)的最大挑戰(zhàn)就是數(shù)據(jù)管理。
敲重點，跟以往單體應(yīng)用的共享數(shù)據(jù)庫不同，微服務(wù)應(yīng)用中的每一個服務(wù)“獨享”自己的數(shù)據(jù)庫，服務(wù)之間需要通過 API、事件或消息傳遞的方式來相互訪問對方的數(shù)據(jù)，而不是通過直接訪問對方數(shù)據(jù)庫的方式。
換句話說，理想中的微服務(wù)是封裝自己的數(shù)據(jù)，通過API暴露數(shù)據(jù)出去，從而避免數(shù)據(jù)耦合，這樣每個微服務(wù)的數(shù)據(jù)格式發(fā)生變化也不影響其它微服務(wù)的數(shù)據(jù)調(diào)用。開發(fā)過和升級過大型企業(yè)單體應(yīng)用的人對此會深有體會，一旦有人改變了數(shù)據(jù)庫 schema，整個應(yīng)用都有可能啟動不起來，團(tuán)隊開發(fā)效率會大大降低。
微服務(wù)架構(gòu)并不盡善盡美，適合自己的方案才是王道。
不難理解，微服務(wù)數(shù)據(jù)是犧牲強(qiáng)一致性而通過最終一致性的方式來管理，這對數(shù)據(jù)的劃分帶來很大難度，比如不能再用 join 的方式訪問不同服務(wù)之間的數(shù)據(jù)表，實際當(dāng)中也比較難做到或者做起來很麻煩，現(xiàn)在也沒有成熟且好用的庫或框架提供微服務(wù)的數(shù)據(jù)管理，而且某些應(yīng)用確實需要強(qiáng)一致性。
而此時，我們不能通盤否定此類應(yīng)用微服務(wù)化的可行性，應(yīng)該適當(dāng)折中或“妥協(xié)”，采用 miniservice。
Miniservice 在開發(fā)與部署的獨立性和敏捷性方面類似于微服務(wù)（microservice），但沒有微服務(wù)那么強(qiáng)的約束。通常情況下，一個 miniservcie 可以提供多個功能，這些功能之間可以共享數(shù)據(jù)庫。這個時候千萬不要害怕混合架構(gòu)，不要害怕自己的微服務(wù)應(yīng)用是否“正統(tǒng)”，“think big，start small，move fast”才是我們應(yīng)該遵循的哲學(xué)。
因此，一個企業(yè)應(yīng)用里既有 microservice 也有 miniservice，甚至有單體部分（可以稱之為 macroservice）都是可以接受的。
以一個電商平臺舉例，在整個場景里面，業(yè)務(wù)開發(fā)人員面對的主要壓力來自前端頻繁的變動，因為要應(yīng)對頻繁的促銷、推廣、降價等活動，所以面對消費者最前端的業(yè)務(wù)需要快速迭代。消費者會不停的瀏覽商品，最終產(chǎn)生交易的請求數(shù)量要遠(yuǎn)低于獲取商品信息的請求數(shù)量，因此將前端業(yè)務(wù)無狀態(tài)化，進(jìn)行微服務(wù)拆分、解耦，便可以快速應(yīng)對市場變化，靈活做出改變。
那是不是把整個平臺都做到微服務(wù)級別會變得更好？答案是“不確定”，因為當(dāng)微服務(wù)量級到達(dá)一定程度，由此產(chǎn)生的管理和運維壓力是指數(shù)級增長的。而實際上，對于有些業(yè)務(wù)來講也沒有必要微服務(wù)化，比如很多電商平臺都有 2B 的業(yè)務(wù)，其業(yè)務(wù)變化的頻度和壓力沒有 2C 那么大，那以 macroservices 或者 miniservices 的方式去交付也是可以的。
開發(fā)人員應(yīng)該分析在整個應(yīng)用架構(gòu)體系中，哪些適合微服務(wù)化，哪些亟需微服務(wù)化。
實踐出真知
在上面的電商案例中，我們提到了服務(wù)無狀態(tài)化，之所以期望服務(wù)無狀態(tài)化，是因為無狀態(tài)應(yīng)用可以做到快速的擴(kuò)縮容，可以應(yīng)對井噴流量，可以最大效率的利用計算資源。
我們經(jīng)常聽到，以無狀態(tài)為榮，以有狀態(tài)為恥，說的就是對于一個服務(wù)要盡量無狀態(tài)化它，比如用戶 session 管理，以前我們在業(yè)務(wù)邏輯模塊進(jìn)行管理，導(dǎo)致這些模塊不能按照無狀態(tài)方式任意伸縮。我們可以把這些 session 的管理抽取出來放到一個高可用或分布式的緩存中管理，業(yè)務(wù)模塊通過調(diào)用API的方式去獲取 session，這樣就實現(xiàn)了這些模塊的無狀態(tài)化。
但這并不意味著所有服務(wù)都做到無狀態(tài)才是最好的，開發(fā)者要細(xì)細(xì)思考自己的業(yè)務(wù)模型并進(jìn)行服務(wù)拆分，不要為了無狀態(tài)而無狀態(tài)，因為總是會存在有狀態(tài)服務(wù)的。
第二階段進(jìn)階—— 改造遺留應(yīng)用
如果我們經(jīng)過認(rèn)真思考后仍決定對遺留應(yīng)用進(jìn)行微服務(wù)化，比如需要新增功能、快速迭代現(xiàn)有功能等，那么最好遵循一些最佳實踐經(jīng)驗。顯然，另起爐灶開發(fā)一套新的系統(tǒng)不太現(xiàn)實，失敗的概率非常高。
第一點注意：新增功能點不能再在原有單體應(yīng)用基礎(chǔ)上開發(fā)，而是需要按照微服務(wù)方式開發(fā)，但由于這個微服務(wù)是隸屬于原來單體應(yīng)用的一部分功能，所以通常情況需要訪問單體應(yīng)用的數(shù)據(jù)，這個時候需要通過API的方式訪問，以防止二者之間發(fā)生緊耦合。對于單體部分來說，無論是采用 Facade，還是 Adapter 或 Translator 模式提供 API，都是為新增的微服務(wù)模塊提供松耦合的訪問方式。
第二點注意：對于已有的單體部分也可以逐步微服務(wù)化，可選擇經(jīng)常變化、需要快速迭代滿足用戶需求的部分著手進(jìn)行改造。經(jīng)過幾輪改造后要么整體替換掉原單體應(yīng)用，要么剩下的是穩(wěn)定不變的單體部分，周圍就都是改造過的微服務(wù)混合架構(gòu)了。
第三階段收放自如——Service Mesh
Service mesh 是微服務(wù)架構(gòu)的一部分，它本質(zhì)上是一個分布式計算中間件，通過攔截流量和安置策略來管理和優(yōu)化服務(wù)之間的通信，使得服務(wù)變得更加健壯和安全。通常會提供微服務(wù)之間認(rèn)證、鑒權(quán)、加密、服務(wù)發(fā)現(xiàn)、請求路由、負(fù)載均衡、服務(wù)自愈等功能。
部署微服務(wù)應(yīng)用，service mesh 是必不可少的部分。這是因為微服務(wù)應(yīng)用是一個分布式的應(yīng)用，因此相對于單體應(yīng)用來說在穩(wěn)定性、可管理性等方面都有很大難度，需要有 service mesh來管理幫助服務(wù)變得更加健壯和安全。
因此，Service mesh 選型也是比較重要的，經(jīng)常聽到有人糾結(jié)是選擇 Istio 還是 Spring Cloud 等。我們認(rèn)為 Istio 是 service mesh 的發(fā)展方向，從架構(gòu)來說，它解耦了控制平面和數(shù)據(jù)平面，使得開發(fā)者可以專注于應(yīng)用業(yè)務(wù)邏輯的開發(fā)，而復(fù)雜的分布式應(yīng)用服務(wù)之間的通信交給 service mesh 來控制。
Spring Cloud 在架構(gòu)設(shè)計理念上是落后的，試想一下，開發(fā)者在開發(fā)微服務(wù)的時候還要思考如何在代碼中實現(xiàn)熔斷、灰度發(fā)布、負(fù)載均衡等問題，負(fù)擔(dān)是非常重的。
更重要的是 Spring Cloud 類型的 service mesh 只支持 Java 語言，完全違背微服務(wù)可以任選語言開發(fā)的主張，而且有 vendor lock-in 嫌疑。
Istio 身上鮮明的標(biāo)簽很多：天然適合 Kubernetes 平臺，不侵入代碼，無語言綁定，但不得不承認(rèn)，Istio 還在發(fā)展過程當(dāng)中，目前也有一些問題亟待解決：
性能依然不夠理想
基于 Istio 實現(xiàn)的微服務(wù)，由于虛擬化、轉(zhuǎn)發(fā)等因素造成的性能損耗依然過大，不過積極的方面是我們看到一方面這是社區(qū)持續(xù)改進(jìn)的重點，另一方面我們看到大家在做一些有效的嘗試，比如通過 cilium 做 service mesh 的 proxy，提升性能；
門檻高
Istio 雖然控制面做的很優(yōu)秀，但上手成本依然很高，很多企業(yè)用戶還處在容器化改造階段，以一種復(fù)雜面貌去呈現(xiàn)是很難很快融入企業(yè) IT 架構(gòu)中的；
落地實踐少
雖然社區(qū)火熱，被談?wù)摰臒岫群芨�，但企業(yè)用戶或者在觀望，或者在嘗試，我們能看到的是有技術(shù)實力的互聯(lián)網(wǎng)公司將 Istio 中的某個組件拆解出來，或改造、或接入他們現(xiàn)有微服務(wù)治理平臺，但這又會造成一種和社區(qū)主分支不一致的問題，為將來能否和社區(qū)保持一致帶來些許擔(dān)心，是否會走上廠商綁定的老路還需要觀察。
值得一提的是，在2018年上海 KubeCon 大會上，Google 的開發(fā)者講述了在美國三家公司成功將 Istio 用于生產(chǎn)的案例，相信類似的事情會發(fā)生的越來越多，也期待今年上海的 KubeCon 能看到更多來自 Istio 的分享。
雖然 Istio 存在上述問題，但我們更應(yīng)看到其社區(qū)正在飛速增長，就好比一兩年前 k8s、docker swarm 和 Mesos 之爭一樣，那個時候 k8s 強(qiáng)大的生態(tài)活躍度為它最終勝利打下了良好的基礎(chǔ)，我們認(rèn)為 Istio 就是在 service mesh 領(lǐng)域的 k8s，未來很有可能會贏得這個領(lǐng)域的主導(dǎo)地位。
當(dāng)一個應(yīng)用的微服務(wù)越來越多的時候，service mesh 變得非常重要，而且目光看得更遠(yuǎn)一些，隨著 FaaS 步入業(yè)務(wù)開發(fā)者的視野，大家越來越享受這種便捷、靈活的開發(fā)方式，這意味著以服務(wù)視角的開發(fā)模式會越來越流行，因此 service mesh 框架會變得越來越重要。
綜上所述，通過 Istio 構(gòu)建微服務(wù)治理屏幕，學(xué)習(xí)曲線起點比較高，運維也非常麻煩，運維人員關(guān)注的是功能的輸出，比如熔斷、限流、灰度發(fā)布等，但 Istio 要求他們先要部署組件，編輯 yaml，了解各種抽象的參數(shù)，這就好比在看 3D 電影前，讓觀眾自己先要組裝 3D 眼鏡一樣。
因此，微服務(wù)進(jìn)階之路道阻且長，企業(yè)需要一個平臺級商業(yè)產(chǎn)品，可以從業(yè)務(wù)視角來管理微服務(wù)的可視化工具或者平臺，降低用戶的學(xué)習(xí)和運維成本，提高用戶的業(yè)務(wù)價值輸出能力，幫助用戶重塑數(shù)字化時代核心競爭力。
重磅預(yù)告
K8s
Meetup
QingCloud X CNCF
KubeSphere and Friends
12 月 14 日
干貨內(nèi)容、圓桌討論
邀全北京開源技術(shù)愛好者暢聊容器
滿足每一顆追求極致的心
來源：青云QingCloud
來源：青云QingCloud
掃碼或點擊閱讀原文立即預(yù)約席位
