【話題討論】理解微服務(wù)架構(gòu)，實踐云原生應(yīng)用！

post200

微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？
CloudNative 最大的思維轉(zhuǎn)變當屬 Stateless Infrastructure（無狀態(tài)基礎(chǔ)設(shè)施）。這樣可以大幅度保障應(yīng)用的可用性和水平擴展能力，當傳統(tǒng)的計算資源和存儲資源已經(jīng)通過云計算技術(shù)達到了海量。應(yīng)用的瓶頸就來自于應(yīng)用架構(gòu)和基礎(chǔ)設(shè)施結(jié)構(gòu)。如果還在思考基礎(chǔ)設(shè)施的狀態(tài)如何監(jiān)控和保存，就又進入了老的思維模式，只不過換了新的工具而已。

aloki

1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
微服務(wù) (Microservices) 是一種軟件架構(gòu)風(fēng)格，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ)，利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān) (Language-Independent/Language agnostic) 的 API 集相互通信。
盡管“微服務(wù)”早已成為一種極具人氣的架構(gòu)類型，但這一名稱卻并不能準確反映服務(wù)的實際規(guī)�！�—換言之，“微”服務(wù)并不一定微，具體規(guī)模可謂多種多樣。規(guī)模較小的團隊則由六人組成，負責(zé)支持六項服務(wù)。

2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
·提升開發(fā)交流，每個服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解；
·服務(wù)獨立測試、部署、升級、發(fā)布；
·按需定制的DFX，資源利用率，每個服務(wù)可以各自進行x擴展和z擴展，而且，每個服務(wù)可以根據(jù)自己的需要部署到合適的硬件服務(wù)器上；
·每個服務(wù)按需要選擇HA的模式，選擇接受服務(wù)的實例個數(shù)；
·容易擴大開發(fā)團隊，可以針對每個服務(wù)（service）組件開發(fā)團隊；
·提高容錯性（fault isolation），一個服務(wù)的內(nèi)存泄露并不會讓整個系統(tǒng)癱瘓；
·新技術(shù)的應(yīng)用，系統(tǒng)不會被長期限制在某個技術(shù)棧上；

微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前，也需要認清它所帶來的挑戰(zhàn)。

3.微服務(wù)在實踐過程中最大的難點是什么？
·開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性；
·服務(wù)之間的分布式通信問題；
·服務(wù)的注冊與發(fā)現(xiàn)問題；
·服務(wù)之間的分布式事務(wù)問題；
·數(shù)據(jù)隔離再來的報表處理問題；
·服務(wù)之間的分布式一致性問題；
·服務(wù)管理的復(fù)雜性，服務(wù)的編排；
·不同服務(wù)實例的管理。

4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
雖然使用一般的服務(wù)器虛擬化技術(shù)就能應(yīng)用于微服務(wù)的管理，但容器技術(shù) (Container Technology) 如 Docker 會更加地適合發(fā)展微服務(wù)的運算資源管理技術(shù)。Docker
作為一種開源的應(yīng)用容器引擎，幫助開發(fā)者將他們的應(yīng)用以及依賴打包到一個可移植的容器中，便于應(yīng)用的部署和擴展。而隨之產(chǎn)生的微容器概念和微服務(wù)正好相輔相成，通過Docker 封裝的應(yīng)用可以輕松運行在以擴容能力見長的云計算平臺上。數(shù)人云作為專業(yè)的數(shù)據(jù)中心管理系統(tǒng)，提供了基于 Mesos 和Docker 技術(shù)的企業(yè)級容器云生產(chǎn)環(huán)境，通過一鍵部署、橫向擴展、持續(xù)集成等特性，助力微服務(wù)架構(gòu)在企業(yè)應(yīng)用環(huán)境的實踐。

5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
單個微服務(wù)在上線的時候，會向服務(wù)探索中心（如：Consul）注冊自己的 IP 位置、服務(wù)內(nèi)容，如此一來就不需要向每個微服務(wù)表明自己的 IP 位置，也就不用替每個微服務(wù)單獨設(shè)置。當服務(wù)需要調(diào)用另一個服務(wù)的時候，會去詢問服務(wù)探索中心該服務(wù)的 IP 位置為何，得到位置后即可直接向目標服務(wù)調(diào)用。

這么做的用意是可以統(tǒng)一集中所有服務(wù)的位置，就不會分散于每個微服務(wù)中，且服務(wù)探索中心可以每隔一段時間就向微服務(wù)進行健康檢查（如透過：TCP 調(diào)用、HTTP 調(diào)用、Ping），倘若該服務(wù)在時間內(nèi)沒有回應(yīng)，則將其從服務(wù)中心移除，避免其他微服務(wù)對一個無回應(yīng)的服務(wù)進行調(diào)用。

laputa73

這個話題比較熱門，
1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
這個問題其實是微服務(wù)最核心的問題。
微服務(wù)其實并沒有明確的定義，相對于單體應(yīng)用，微服務(wù)有明顯的差異。
但是相對于分布式的多服務(wù)體系，微服務(wù)的差異體現(xiàn)在哪里？
傳統(tǒng)的SOA同樣有服務(wù)注冊、服務(wù)網(wǎng)關(guān)、服務(wù)路由。
微服務(wù)雖然可以脫離網(wǎng)關(guān)，只通過注冊中心尋址，p2p調(diào)用，但是最佳的推薦應(yīng)用方式仍然是通過網(wǎng)關(guān)。
所以，微服務(wù)更多是一個理念，而不是一個明確的概念。
微服務(wù)是不是越微越好？
答案我認為是否定的。
一個上百個api的系統(tǒng)，通過上百個服務(wù)來實現(xiàn)，會給運維來來無窮無盡的煩惱。
相反，類似的功能，聚合到一個服務(wù)中集中實現(xiàn)，效率更高�？傮w分為10來個服務(wù)可能就足夠，
從單體到分布式集群是一個質(zhì)的變化，但是從分布式到微服務(wù)，只是一個量的調(diào)整。

2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
微服務(wù)最大的優(yōu)勢是統(tǒng)一了分布式RPC接口，讓進程間通信和服務(wù)通信成為了統(tǒng)一模式，
只要分布式調(diào)用的需求存在，微服務(wù)的思想就在。
相對于傳統(tǒng)的單體系統(tǒng)，微服務(wù)主要的革命是去掉了session，強制api無狀態(tài).

3.微服務(wù)在實踐過程中最大的難點是什么？
粒度拆分的決策。
服務(wù)之間數(shù)據(jù)一致性問題。
運維問題。
多語言問題。
還有一個內(nèi)外劃分的問題，傳統(tǒng)的系統(tǒng)功能明確，內(nèi)部系統(tǒng)走rpc,外部系統(tǒng)通過soa相互通信。現(xiàn)在都統(tǒng)一成微服務(wù)了。
誰是內(nèi)，誰是外？系統(tǒng)邊界在哪？服務(wù)中心需要建一套，還是多套？

4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
沒有容器(docker)，也會有微服務(wù)。各種語言都有自己的web/rest app容器。
例如java的spring boot, python的flask.
但是有了docker容器，微服務(wù)的隔離更徹底，部署更清晰。
而且，依托k8s的容器調(diào)度，可以實現(xiàn)更高層次的微服務(wù)治理。

5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
微服務(wù)的數(shù)據(jù)同步是個很復(fù)雜的問題。
理論上微服務(wù)之間只存在api調(diào)用. 但是每個微服務(wù)自己搞一個數(shù)據(jù)庫是不現(xiàn)實的。
所以系統(tǒng)中需要有一部分服務(wù)，單獨處理數(shù)據(jù)。成為數(shù)據(jù)服務(wù)。
然后通過這些服務(wù)，暴露數(shù)據(jù)操作接口。
對于這些數(shù)據(jù)服務(wù)，可以直接操作數(shù)據(jù)庫，本質(zhì)上和傳統(tǒng)的服務(wù)/DAO這些沒有太大差別。

微服務(wù)區(qū)分內(nèi)外，和外部服務(wù)交互一定要過網(wǎng)關(guān)。
如果從外部獲取數(shù)據(jù)，量小的走api,量大的可能走專用通道，例如文件，隊列。

6.微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）
云原生的概念是相對于直接把老系統(tǒng)遷移到容器、虛機部署而言的。
實際上，只要用上了docker+微服務(wù)這一套體系。支持了集群擴縮容，自然就是云原生了。

多說一句，目前的的微服務(wù)架構(gòu)，spring cloud還是主流
但是和云原生結(jié)合，service mesh(istio)才是更純粹的微服務(wù)架構(gòu)。

oswald

請問各位大佬，什么時候應(yīng)該使用微服務(wù)？

nt1979

哪些應(yīng)用可以從微服務(wù)收益？

mysdirma

回復(fù) 16# nt1979

• 記錄型系統(tǒng)(System of Record)將從微服務(wù)方法中獲益最多。例如可將大型應(yīng)用按相對獨立的業(yè)務(wù)功能分解成若干個微服務(wù)實現(xiàn)。

• 交互型系統(tǒng)(System of Engagement)也將受益于微服務(wù)方法，例如渠道應(yīng)用可以應(yīng)用“后端服務(wù)前端”的模式實現(xiàn)。

• 分析型系統(tǒng)(System of Insight)則可能對微服務(wù)受益不多。其他架構(gòu)模式如管道及過濾模式可能更適用于分析型系統(tǒng)。

  
  

renxiao2003

1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
將單一應(yīng)用劃分為一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、配合，為用戶提供最終價值的架構(gòu)體系。而每個服務(wù)運行在獨立的進程中，服務(wù)之間采用輕量級通信（通常是基于HTTP協(xié)議的Rest API），并且每個服務(wù)都承載著獨立的業(yè)務(wù)單元責(zé)任，能夠被獨立的部署和發(fā)布。
微服務(wù)不需要像普通服務(wù)那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務(wù)是需要與業(yè)務(wù)能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設(shè)計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發(fā)現(xiàn)，其中的指導(dǎo)建議是非常實用的。在決定將所有組件組合到一起時，開發(fā)人員需要非常確信這些組件都會有所改變，并且規(guī)模也會發(fā)生變化。服務(wù)粒度越粗，就越難以符合規(guī)定原則。服務(wù)粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權(quán)衡過程是非常復(fù)雜的，我們要在配置和資金模型的基礎(chǔ)上考慮到基礎(chǔ)設(shè)施的成本問題。
微服務(wù)到底應(yīng)該微到什么程度，根據(jù)個人觀點，不能太微，也不能不微。太微了容易造成資源的浪費，比如一個計算器功能，我們把加減乘除都做成微服務(wù)（即加是微服務(wù)，減也是）那么不管是使用者還是提供者都很繁瑣，而且容易造成資源浪費，畢竟就算是用容器，容器本身也是需要一個運行環(huán)境的；如果不微，把所有功能都糅合到一起，那么哪天更新一個功能可能就要停止所有的服務(wù)。造成所有服務(wù)中斷。
2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
優(yōu)勢：首先，通過分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題。第二，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團隊來開發(fā)。第三，微服務(wù)架構(gòu)模式是每個微服務(wù)獨立的部署。最后，微服務(wù)架構(gòu)模式使得每個服務(wù)獨立擴展。
將一個復(fù)雜的業(yè)務(wù)分解成若干小的業(yè)務(wù)，每個業(yè)務(wù)拆分成一個服務(wù)，服務(wù)的邊界明確，將復(fù)雜的問題簡單化。由于微服務(wù)系統(tǒng)是分布式系統(tǒng) ，服務(wù)與服務(wù)之間沒有任何的禍合 。服務(wù)與服務(wù)之問通過 HTTP 網(wǎng)絡(luò)通信協(xié)議來通信，單個微服務(wù)內(nèi)部高度禍合，服務(wù)與服務(wù)之間完全獨立，無調(diào)合。如果是一個單體的應(yīng)用，由于業(yè)務(wù)的復(fù)雜性、代碼的禍合性，以及可能存在的歷史問題。微服務(wù)的每個服務(wù)單元都是獨立部署的 ，即獨立運行在某個進程里。微服務(wù)的修改和部署對其他服務(wù)沒有影響。微服務(wù)在 CAP 理論中采用的是 AP 架構(gòu)，即 具有高可用和分區(qū)容錯 的特點 。
微服務(wù)（架構(gòu)）應(yīng)該是未來軟件（架構(gòu)）的趨勢。
3.微服務(wù)在實踐過程中最大的難點是什么？
『微服務(wù)』強調(diào)了服務(wù)大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組。
微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring Boot架構(gòu)，對一個單體式web應(yīng)用，測試它的REST API，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。
4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring Boot架構(gòu)，對一個單體式web應(yīng)用，測試它的REST API，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。
部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。
微服務(wù)與容器結(jié)合能夠更好的發(fā)揮和充分的利用計算機的資源。
5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
對外部有了依賴
微服務(wù)架構(gòu)設(shè)計中有一條重要的原則叫嚴出寬進，嚴出意思就是說你提供給其他服務(wù)的東西要盡可能的進行嚴格的校驗。寬進就是你調(diào)用別人的接口要寬容，兼容各種情況。比如說你需要考慮別人的節(jié)點down了/api超時/api不可用等等因素。

為了解決這個問題，我們必須要針對具體業(yè)務(wù)，分析依賴類型，是強依賴還是弱依賴，強依賴包裝成自己的服務(wù)異常返回碼/或者直接告訴前端調(diào)用不可用。弱依賴，catch所有異常，無論依賴方發(fā)生什么，不能影響我的接口返回。

此外，我依賴的服務(wù)某段時間內(nèi)接口錯誤率很高，調(diào)用方還在不停的發(fā)送請求，那么就會一直得到錯誤的結(jié)果，這時候這些請求其實是無效的，所以這時候需要客戶端熔斷，不再去調(diào)用服務(wù)方，給服務(wù)方恢復(fù)的時間，等過段時間再去重試，發(fā)現(xiàn)服務(wù)方可用時，再去調(diào)用。

網(wǎng)絡(luò)調(diào)用

網(wǎng)絡(luò)調(diào)用是耗時的，所以我們需要利用池化技術(shù)，復(fù)用連接，比如在單體應(yīng)用中我們需要與數(shù)據(jù)庫連接，會利用到數(shù)據(jù)庫連接池來提高數(shù)據(jù)操作效率。那么微服務(wù)調(diào)用也是這么個道理，我們與其他服務(wù)建議http/tcp連接，也需要建立連接池。另外一個服務(wù)可能會依賴多個微服務(wù)，不能因為和某個服務(wù)之間的連接出了問題，影響到與其他服務(wù)的連接，所以需要做連接池隔離。

服務(wù)間調(diào)用有可能失敗，所以我們需要有重試機制，比如因為網(wǎng)絡(luò)抖動引發(fā)的超時問題，我們可以通過重試提高API的可用性。
但是思考一下壞的情況，某段時間網(wǎng)絡(luò)或者服務(wù)端真的有問題了�？蛻舳顺瑫r時間設(shè)置的很大的話，客戶端等待的時間就會很長，然后再加上重試機制，就會將客戶端的連接占滿，造成客戶端相關(guān)API不可用。
6.微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）
Cloud Native翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續(xù)交付（Continuous Delivery）、微服務(wù)（MicroServices）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據(jù)商業(yè)能力對公司進行重組。Cloud Native既包含技術(shù)（微服務(wù)，敏捷基礎(chǔ)設(shè)施），也包含管理（DevOps，持續(xù)交付，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術(shù)、企業(yè)管理方法的集合。

incle

微服務(wù)通常由重寫一個模塊開始。要把整個巨石型的應(yīng)用重寫是有很大的風(fēng)險的，也不一定必要。我們向微服務(wù)遷移的時候通常從耦合度最低的模塊或?qū)�擴展性要求最高的模塊開始，

把它們一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術(shù)和語言和框架，然 后單獨布署。 它通常不依賴其他服務(wù)。微服務(wù)中常用的API Gateway的模式主要目的也不是重用代碼，

而是減少客戶端和服務(wù)間的往來。API gateway模式不等同與Facade模式，我們可以使用如future之類的調(diào)用，甚至返回不完整數(shù)據(jù)。