?OSC 第 130 期高手問答 — 究竟什么才是微服務(wù)？

url：https://www.oschina.net/question/2720166_2201257

本文截取自“OSCHINA 本期高手問答(10 月 17 日-10 月 23 日) 我們請來了@黃勇為大家解答關(guān)于微服務(wù)架構(gòu)方面的問題。”

引用來自“sofn”的評論

@黃勇?: 聽說微服務(wù)是個(gè)很大的概念，Dubbo只是實(shí)現(xiàn)了其中一小部分，請問完善的微服務(wù)架構(gòu)是什么樣的？Spring Cloud是否算是完善的微服務(wù)？

感謝您的提問！

微服務(wù)架構(gòu)的范圍比較大，Dubbo 和 Spring Cloud 都只是解決了微服務(wù)的一部分問題，并未完全覆蓋。稍后我也出一篇文章，將上周去 QCon 分享的微服務(wù)架構(gòu)，給大家再次做一個(gè)介紹。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-24 10:32)

引用來自“祥子-匠心”的評論

@黃勇?微服務(wù)的開源技術(shù)選型能介紹幾種嗎？Spring Cloud如何解決跨語言的問題呢

感謝您的提問！

比較知名的微服務(wù)開源技術(shù)選型莫過于 Spring Cloud，它對 Netflix 提供的相關(guān)組件做了一定的封裝，讓開發(fā)者更容易上手。當(dāng)然，我更加希望本書所先介紹的開源技術(shù)選型會(huì)被更多人接受與應(yīng)用。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 14:15)

引用來自“p2ng”的評論

@黃勇?:如何更好理解【微服務(wù)】這個(gè)“微”字。從設(shè)計(jì)之初，開發(fā)，部署，運(yùn)維，監(jiān)控，等有什么地方（基于你的過往歷程）需要關(guān)注的

感謝您的提問！

我認(rèn)為「微」并非它的體積足夠小，而是它的責(zé)任足夠單一，很多人誤解了「微」的真實(shí)含義，認(rèn)為服務(wù)拆分得足夠小就是微服務(wù)了，其實(shí)并非這樣。此外，「微」還有“微不足道”的意思，也就是說，某個(gè)服務(wù)出現(xiàn)故障，它不會(huì)影響整個(gè)系統(tǒng)。

引用來自“Yuhoo2013”的評論

@黃勇?: 微服務(wù)拆分如果粒度太細(xì)，會(huì)不會(huì)導(dǎo)致維護(hù)成本增加？響應(yīng)時(shí)間增加？事務(wù)控制如何實(shí)現(xiàn)？

感謝您的提問！

1. 微服務(wù)粒度問題取決于我們對業(yè)務(wù)的理解與把控能力，無需太細(xì)。

2. 可借用消息隊(duì)列和日志追蹤進(jìn)行事務(wù)控制，也可使用CQRS 或 Event Sourcing 解決方案。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 14:04)

引用來自“西夏一品堂”的評論

@黃勇?: ?目前，微服務(wù)的事務(wù)是大家最關(guān)系的？請問，現(xiàn)在業(yè)界有沒有開源的解決微服務(wù)事務(wù)的項(xiàng)目

感謝您的提問！

微服務(wù)的事務(wù)控制比較復(fù)雜，我們需要做到盡可能避免服務(wù)之間的調(diào)用，這取決于我們對微服務(wù)切分的粒度控制。業(yè)界有 CQRS 與 Event Sourcing 來解決微服務(wù)的事務(wù)問題，希望對您有幫助。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:30)

引用來自“歸園田居”的評論

@黃勇?:微服務(wù)具體應(yīng)用于哪些場景？

感謝您的提問！

我認(rèn)為在以下幾種情況下，可考慮使用微服務(wù)架構(gòu)：

• 應(yīng)用變得越來越大時(shí)
• 項(xiàng)目存在多種開發(fā)語言時(shí)
• 感覺到經(jīng)典架構(gòu)模式太重時(shí)
• 修改了一個(gè) bug 需要平滑升級時(shí)
• 想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時(shí)

當(dāng)然還有其他使用場景，但微服務(wù)不是萬靈丹，不能適用于所有場景。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:28)

引用來自“羅厚付”的評論

@黃勇?微服務(wù)框架是在Soa的基礎(chǔ)上提出的嗎？在技術(shù)選型要注意哪些點(diǎn)，用spring cloud還是spring boot?怎樣做到輕量級，有哪些參考？

感謝您的提問！

1. 我認(rèn)為微服務(wù)是傳統(tǒng) SOA 的輕量級解決方案，它讓 SOA 更加容易落地。

2. 在微服務(wù)技術(shù)選型方面，我建議竟可能地輕量級，做到“進(jìn)可攻退可守”，至于 Spring Cloud 還是其他框架，完全取決于我們對技術(shù)本身的理解以及對業(yè)務(wù)的把控能力，技術(shù)也業(yè)務(wù)需要相互結(jié)合才能產(chǎn)生價(jià)值。

3. 希望這本書中所設(shè)計(jì)的輕量級開源方案，會(huì)幫助您更快地搭建微服務(wù)架構(gòu)。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:23)

• 引用來自“機(jī)器貓123”的評論

  @黃勇?老師你好，才看到osc請你來做問答，很高興。從上次你的《架構(gòu)探險(xiǎn)：從零開始寫Java Web框架》的問答，我就很關(guān)注你。還買了你的這本書，很受用。這次你的這本關(guān)于輕量級微服務(wù)，我有幾個(gè)問題，你的這本書里關(guān)于微服務(wù)的技術(shù)選型是怎么考量的？書中提到了spring boot，你對與spring的這個(gè)技術(shù)怎么看？微服務(wù)的應(yīng)用場景大部分是什么？現(xiàn)在微信小程序比較流行，微服務(wù)會(huì)成為小程序的技術(shù)首選嗎？

  感謝您的提問！

  1. 這本書中關(guān)于微服務(wù)的技術(shù)選型問題，我做了大量的思考并實(shí)踐，所選擇的方案均為開源，且非常輕量級，目的是幫助大家能夠快速搭建這款輕量級微服務(wù)架構(gòu)。

  2. 雖然這本書講到的微服務(wù)開發(fā)框架是 Spring Boot，用過的人都知道它有明顯的優(yōu)勢，當(dāng)然也有明顯的劣勢，畢竟底層還是基于 Spring，而 Spring 從當(dāng)初的輕量級似乎變得越來越重，我希望有更好的輕量級框架可以出現(xiàn)，所以當(dāng)初寫了一款 Smart 框架以及《架構(gòu)探險(xiǎn)》第一本書，目的只是拋磚引玉，希望有更多的朋友都能投身到國內(nèi)開源行業(yè)中，創(chuàng)造更優(yōu)秀的開源項(xiàng)目。

  3. 我非常看好微信小程序的未來，但微服務(wù)是否成為小程序的技術(shù)首選，我不太敢下次評論，咱們一起靜觀其變吧。

  --- 共有 1 條評論 ---
  • 機(jī)器貓123謝謝黃老師。?(3個(gè)月前)??
  評論(1)|?引用此答案|?舉報(bào)?(2016-10-20 11:20)
• 
  

引用來自“風(fēng)箏上的少年”的評論

@黃勇?:微服務(wù)怎么解決調(diào)用鏈過長導(dǎo)致的調(diào)試或異常追蹤過難的問題呢？

感謝您的提問！

調(diào)用鏈追蹤是微服務(wù)落地的一個(gè)挑戰(zhàn)，我們一般通過追蹤平臺(tái)來解決，推薦使用開源的 Zipkin。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:12)

引用來自“飛天蘿卜”的評論

@黃勇?:微服務(wù)目前有什么成熟的一整套開源方案嗎？包括測試、版本控制，發(fā)布流程，代碼錯(cuò)誤回滾？

感謝您的提問！

業(yè)界也有其他優(yōu)秀的微服務(wù)開源方案，例如 Java 領(lǐng)域的 Netflix 與 Spring Cloud。當(dāng)然，我更希望本書所提到的開源方案，可以被更多人接受并應(yīng)用。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:09)

引用來自“l(fā)qjava”的評論

@黃勇?:微服務(wù)是否就一定是進(jìn)程級別的？在同一個(gè)進(jìn)程內(nèi)實(shí)現(xiàn)微服務(wù)可行嗎？如果一個(gè)服務(wù)就一個(gè)進(jìn)程，這樣是不是會(huì)耗費(fèi)大量系統(tǒng)資源？

感謝您的提問！

1. 微服務(wù)講究的是服務(wù)可以獨(dú)立開發(fā)與部署，如果在進(jìn)程內(nèi)進(jìn)行微服務(wù)，將帶來很高的復(fù)雜度，就像當(dāng)年的 OSGi 那樣，理念非常好，但實(shí)踐起來卻困難重重。

2. 一個(gè)服務(wù)一個(gè)進(jìn)程，這樣讓服務(wù)的隔離性更加徹底，配合 Docker 容器技術(shù)，可以更加高效低利用服務(wù)器硬件與網(wǎng)絡(luò)資源。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:06)

• 引用來自“Rwing”的評論

  @黃勇?:請問微服務(wù)的核心系統(tǒng)是什么？是微服務(wù)的發(fā)現(xiàn)和組織嗎？每個(gè)微服務(wù)很好做，如何把他們組合起來是不是有現(xiàn)成的系統(tǒng)可以參考、

  感謝您的提問！

  1. 我認(rèn)為微服務(wù)的核心是：服務(wù)注冊中心（Service Registry）與服務(wù)網(wǎng)關(guān)（Service Gateway），它們配合完成服務(wù)注冊與服務(wù)發(fā)現(xiàn)。

  2. 將服務(wù)組合起來也成為“服務(wù)編排”，有多重做法，可以在服務(wù)網(wǎng)關(guān)中進(jìn)行編排，也可以通過中間服務(wù)進(jìn)行編排，我更傾向于后者，這樣確保服務(wù)網(wǎng)關(guān)不包含任何業(yè)務(wù)，更加輕量級。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 11:01)

• 引用來自“zcfrank1st”的評論

  @黃勇?:微服務(wù)的分布式事務(wù)問題如何解決？一般拆分服務(wù)的原則？謝謝！

  感謝您的提問！

  1. 微服務(wù)分布式事務(wù)一般借助消息驅(qū)動(dòng)與日志追蹤的方式來解決，以達(dá)成事務(wù)的“最終一致性”，當(dāng)然市面上也有 CQRS 與 Event Sourcing 解決方案。

  2. 微服務(wù)拆分原則取決于我們對業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 10:57)
  

引用來自“empireghost”的評論

@黃勇?: 微服務(wù)都是通過HTTP方式對外提供？

感謝您的提問！

微服務(wù)對外的接口不一定局限于 HTTP 或 HTTPS，也可以是 TCP，需要根據(jù)具體情況而定。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 10:42)

引用來自“idisikx”的評論

@黃勇?:SOA WebService RESTFul 這些概念有啥本質(zhì)的區(qū)別。開發(fā)者平常使用的那些ajax http接口（含session狀態(tài)的）算的上restful接口嗎？

感謝您的提問！

1. RESTful 是一種架構(gòu)風(fēng)格，SOA 是一種架構(gòu)思想，可以認(rèn)為 RESTful 有助于 SOA 的落地化。

2. RESTful 一般應(yīng)用在 HTTP 協(xié)議上，在前后端分離架構(gòu)中，前端通過 AJAX 技術(shù)發(fā)送 RESTful HTTP 請求到后端，獲取后端 JSON 數(shù)據(jù)，并進(jìn)行界面渲染。同樣，RESTful 也用于微服務(wù)架構(gòu)中，每個(gè)服務(wù)對外暴露 REST API 作為通信接口。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 10:27)

引用來自“Albert-Liu”的評論

@黃勇?:怎樣來控制微服務(wù)的粒度？

就是有沒有什么樣的原則和最佳實(shí)踐來判斷一個(gè)功能（接口）是應(yīng)該屬于A服務(wù)還是應(yīng)該屬于B服務(wù)。

另外，是否有接觸過“領(lǐng)域驅(qū)動(dòng)的分析與設(shè)計(jì)方法(DDD)”，你是如何理解“DDD ”與“微服務(wù)”之間關(guān)系的？

感謝您的提問！

1. 微服務(wù)的粒度控制取決于我們對業(yè)務(wù)的理解與把控能力，一切所謂的原則都是不靠譜的。

2. DDD 是基于領(lǐng)域?qū)ο蟮脑O(shè)計(jì)思想，微服務(wù)是基于服務(wù)的業(yè)務(wù)架構(gòu)，DDD 與微服務(wù)可相輔相成。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-20 10:20)

引用來自“大哈ha”的評論

@黃勇?:可以問下，目前有哪些大公司，大項(xiàng)目在使用微服務(wù)架構(gòu)嗎？

感謝您的提問！

國外的 Google、Amazon、Netflix 等都在使用微服務(wù)架構(gòu)，國內(nèi)也開始有互聯(lián)網(wǎng)與軟件公司在使用微服務(wù)架構(gòu)。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 23:16)

引用來自“阿里巴巴廁所所長”的評論

@黃勇?:Docker容器技術(shù)的出現(xiàn)，為微服務(wù)提供了更便利的條件，比如更小的部署單元，每個(gè)服務(wù)可以通過類似Node.js或Spring Boot的技術(shù)跑在自己的進(jìn)程中。可能在幾十臺(tái)計(jì)算機(jī)中運(yùn)行成千上萬個(gè)Docker容器，這么多Docker容器怎么來有效管理？出錯(cuò)了如何排查呢？

感謝您的提問！

實(shí)際上您提到的是服務(wù)治理問題，目前有大量的技術(shù)可以做到，比如：Google Kubernetes、Apache Mesos、Docker Swarm 等。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 23:12)

引用來自“imlzw”的評論

@黃勇?:針對微服務(wù)的全局id生成策略。不知道黃老師有沒有什么好的建議？

1.看了很多的分布式id生成策略。提到很多id趨勢遞增的策略，這個(gè)有什么用？

2.為什么要讓id具體有順序功能？如何保證順序？

不知道黃老師在實(shí)際項(xiàng)目中用了什么策略，希望能分享一下。

感謝您的提問！

實(shí)際上 ID 生成策略并非是微服務(wù)架構(gòu)所涵蓋的范疇。我認(rèn)為比較好的 ID 生成策略需要結(jié)合您所面臨的實(shí)際需求，一般應(yīng)用場景下，可通過 Redis 來生成并管理 ID，它具備較高的并發(fā)能力，且能確保分布式一致性。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 23:10)

引用來自“蘿卜K”的評論

@黃勇?:微服務(wù)挺多人說玩不起，是不是相對來說實(shí)施成本挺高的？

感謝您的提問！

玩不起包括兩層含義：一是認(rèn)為成本較高；二是擔(dān)心有風(fēng)險(xiǎn)（怕玩掛了）。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 23:07)

引用來自“Elven_Xu”的評論

@黃勇?:我們是小公司，業(yè)務(wù)比較簡單，系統(tǒng)也不是很大，請問是否適合微服務(wù)？微服務(wù)適用于哪些場景？

感謝您的提問！

我認(rèn)為在以下幾種情況下，可考慮使用微服務(wù)架構(gòu)：

• 應(yīng)用變得越來越大時(shí)
• 項(xiàng)目存在多種開發(fā)語言時(shí)
• 感覺到經(jīng)典架構(gòu)模式太重時(shí)
• 修改了一個(gè) bug 需要平滑升級時(shí)
• 想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時(shí)

當(dāng)然還有其他使用場景，但微服務(wù)不是萬靈丹，不能適用于所有場景。

業(yè)務(wù)目前比較簡單，但將來會(huì)變得復(fù)雜，也建議使用微服務(wù)架構(gòu)。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 23:00)

引用來自“owzander”的評論

@黃勇?:服務(wù)間是不是應(yīng)該避免相互間調(diào)用, 由API Gateway來組織各個(gè)服務(wù)？

感謝您的提問！

沒錯(cuò)，應(yīng)該避免服務(wù)間的調(diào)用，而使用服務(wù)網(wǎng)關(guān)作為調(diào)用入口，但我不建議在服務(wù)網(wǎng)關(guān)處組織服務(wù)調(diào)用，而是通過一個(gè)中間服務(wù)來編排，或使用消息驅(qū)動(dòng)方式來完成。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:58)

引用來自“wj2699”的評論

@黃勇?:該在多大規(guī)模的項(xiàng)目中使用微服務(wù)比較合適？微服務(wù)會(huì)增加架構(gòu)復(fù)雜度嗎？帶來的收益是否可以抵消？

感謝您的提問！

1. 我認(rèn)為對于業(yè)務(wù)比較清晰的項(xiàng)目均可使用微服務(wù)架構(gòu)，并非需要具備多大規(guī)模。

2. 微服務(wù)架構(gòu)會(huì)帶來系統(tǒng)的復(fù)雜度（成本），但必然會(huì)帶來一些收益，至于成本和收益是否低效，這取決于我們對微服務(wù)與業(yè)務(wù)的理解與把控能力。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:54)

• 引用來自“逝影落楓”的評論

  @黃勇?:實(shí)施微服務(wù)后，對于開發(fā)成本是不是更高了？

  感謝您的提問！

  我認(rèn)為實(shí)施微服務(wù)并未提高開發(fā)成本，而是提高運(yùn)維成本，一個(gè)好的微服務(wù)架構(gòu)離不開運(yùn)維方面的支持。本書下冊將針對運(yùn)維方面將以描述，敬請期待。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:44)

• 引用來自“tom”的評論

  @黃勇?:聽朋友說：使用docker運(yùn)行java一點(diǎn)優(yōu)勢都沒有，微服務(wù)架構(gòu)，大量啟動(dòng)docker集群，內(nèi)存利用率很低，特亮瞎眼，雖然java運(yùn)行效率很高

  您怎么看？
  

  感謝您的提問！

  Java 應(yīng)用經(jīng) Docker 化后，最明顯的問題是 Docker 鏡像體積較大，啟動(dòng) Docker 容器所占用的系統(tǒng)資源較高。建議根據(jù)實(shí)際業(yè)務(wù)場景，選擇最為合適的開發(fā)語言實(shí)現(xiàn)對應(yīng)的微服務(wù)，而并非局限于 Java 應(yīng)用之上。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:41)
  

• 引用來自“蘿卜Robert”的評論

  @黃勇?:微服務(wù)架構(gòu)我覺得比較適合新項(xiàng)目，如果已有項(xiàng)目那相當(dāng)于要重構(gòu)，或者逐步拆分做微服務(wù)架構(gòu)？是不是這樣？還是有啥更好的方法？

  感謝您的提問！

  1. 對于業(yè)務(wù)流程較為復(fù)雜，且業(yè)務(wù)會(huì)變得逐漸復(fù)雜的項(xiàng)目，可以考慮使用微服務(wù)架構(gòu)。

  2. 對于已有項(xiàng)目而言，可考慮逐步進(jìn)行微服務(wù)化，也可考慮在新業(yè)務(wù)中使用微服務(wù)架構(gòu)。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:38)
  

引用來自“Jayking001”的評論

@黃勇?:微服務(wù)比較適合在那些應(yīng)用場景使用，還是說所有的應(yīng)用服務(wù)，都做成微服務(wù)都好，微服務(wù)在事務(wù)控制方面，容錯(cuò)方面有啥較好的實(shí)踐方式？

感謝您的提問！

1. 我認(rèn)為在以下幾種情況下，可考慮使用微服務(wù)架構(gòu)：

• 應(yīng)用變得越來越大時(shí)
• 項(xiàng)目存在多種開發(fā)語言時(shí)
• 感覺到經(jīng)典架構(gòu)模式太重時(shí)
• 修改了一個(gè) bug 需要平滑升級時(shí)
• 想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時(shí)

當(dāng)然還有其他使用場景，但微服務(wù)不是萬靈丹，不能適用于所有場景。

2. 微服務(wù)的事務(wù)控制本質(zhì)上是分布式事務(wù)控制，建議使用“最終一致性”來確保。

3. 在容錯(cuò)方面，需要有基礎(chǔ)設(shè)施平臺(tái)的支撐，比如服務(wù)網(wǎng)關(guān)的熔斷機(jī)制。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:35)

引用來自“德古拉-大貓”的評論

@黃勇?:從什么角度能區(qū)分出 或者劃分 微服務(wù) 和PRC分布式 之間的區(qū)別或者關(guān)系？

感謝您的提問！

微服務(wù)是一種應(yīng)用架構(gòu)模式，而 RPC 是一種遠(yuǎn)程調(diào)用方式，它們是不一樣的概念；而在微服務(wù)中會(huì)出現(xiàn)服務(wù)之間的調(diào)用，為了確保性能，我們一般采用 RPC 來調(diào)用。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:31)

引用來自“OSC首席醬油黨”的評論

@黃勇?:1.微服務(wù)粒度如何拆分；2.微服務(wù)對網(wǎng)絡(luò)、數(shù)據(jù)庫連接、緩存服務(wù)器等資源的影響；3：微服務(wù)是否需要多版本服務(wù)共存。謝謝回答！

感謝您的提問！

1. 微服務(wù)粒度的拆分取決于我們對業(yè)務(wù)的理解與把控能力。

2. 微服務(wù)對網(wǎng)絡(luò)、數(shù)據(jù)庫、緩存方面較傳統(tǒng)架構(gòu)而言，沒有過高的要求，但對運(yùn)維方面要求較高。

3. 微服務(wù)需要考慮服務(wù)多版本問題，尤其是服務(wù)升級時(shí)，需要做到平滑，對整體系統(tǒng)沒有任何影響。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 22:26)

引用來自“jeffsui”的評論

@黃勇?: 你好！我也有一個(gè)關(guān)于測試的問題想請教。

是不是微服務(wù)更偏重敏捷模式呢？對于測試而言更容易開展工作？自動(dòng)化測試覆蓋率更高？

望不吝賜教。

感謝您的提問！

1. 我認(rèn)為微服務(wù)與敏捷沒有必然的關(guān)系，微服務(wù)講究的是將“化整為零”，敏捷倡導(dǎo)的是“小步快跑”，但兩者可以有效地結(jié)合起來加以應(yīng)用。

2. 較傳統(tǒng)架構(gòu)而言，微服務(wù)的測試復(fù)雜度和覆蓋面將更為廣泛，不僅需要對每個(gè)服務(wù)進(jìn)行測試，而且需要對整體應(yīng)用加以驗(yàn)證。因此，我們需要使用自動(dòng)化測試技術(shù)來提高測試效率。

--- 共有 1 條評論 ---

• jeffsui謝謝您的解答,這么看,對于測試的要求更高了。需要掌握自動(dòng)化測試工具和不同框架的測試技術(shù)。?(3個(gè)月前)??

評論(1)|?引用此答案|?舉報(bào)?(2016-10-19 22:22)

引用來自“wongloong”的評論

@黃勇?:請問：

1.微服務(wù)一般是json格式調(diào)用，與其他調(diào)用方式有什么區(qū)別么？

2.微服務(wù)使用場景是什么樣的？并不是所有的項(xiàng)目都要上微服務(wù)吧？微服務(wù)是把壓力轉(zhuǎn)向到運(yùn)維是么？

3.具體微服務(wù)拆分力度。如果不使用docker，會(huì)給微服務(wù)帶來哪些不便

謝謝！

感謝您的提問！

1. 我認(rèn)為 JSON 格式只是 REST API 返回值的一種，微服務(wù)并非局限于 REST API 通信。

2.?我認(rèn)為在以下幾種情況下，可考慮使用微服務(wù)架構(gòu)：

• 應(yīng)用變得越來越大時(shí)
• 項(xiàng)目存在多種開發(fā)語言時(shí)
• 感覺到經(jīng)典架構(gòu)模式太重時(shí)
• 修改了一個(gè) bug 需要平滑升級時(shí)
• 想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時(shí)

當(dāng)然還有其他使用場景，但微服務(wù)不是萬靈丹，不能適用于所有場景。微服務(wù)對運(yùn)維是有一定的要求的，尤其是自動(dòng)化運(yùn)維。

3. 微服務(wù)切分粒度完全基于我們對自身業(yè)務(wù)的理解與把控能力。如果沒有 Docker 這類容器技術(shù)，可能會(huì)降低微服務(wù)的部署與交付能力。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:54)

引用來自“西夏一品堂”的評論

@黃勇?: ?一個(gè)大服務(wù)怎么拆最好，依據(jù)是什么，拆分力度怎么控制？

感謝您的提問！

建議從整個(gè)業(yè)務(wù)流程來分析，首先抽象出公共服務(wù)，然后采用大粒度的方式來切分，最后逐步細(xì)化切分粒度，這一切都基于對業(yè)務(wù)的理解與把控能力。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:47)

引用來自“平西王”的評論

@黃勇?: 請問，服務(wù)拆分之后，就會(huì)出現(xiàn)，微服務(wù)調(diào)用微服務(wù)的情況，導(dǎo)致效率很慢，接口的QPS很低，怎么解決？

感謝您的提問！

我的建議是，盡可能避免服務(wù)之間的調(diào)用，不妨使用消息隊(duì)列的方式來降低服務(wù)之間的耦合，當(dāng)然必要的直接調(diào)用可使用 RPC 技術(shù)，它具備優(yōu)秀的性能，可確保較高的 QPS。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:45)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“子矜”的評論

@黃勇?: 我想利用微服務(wù)實(shí)現(xiàn)系統(tǒng)的模塊化，便于公共模塊復(fù)用和水平擴(kuò)展，但目前的系統(tǒng)規(guī)模其實(shí)都很小，這種情況是不是不適合使用微服務(wù)？另外，使用REST通信其實(shí)挺麻煩的，還需要封裝一層調(diào)用方法，不知道有沒有類似的問題？

感謝您的提問！

1. 我認(rèn)為微服務(wù)架構(gòu)用于業(yè)務(wù)較復(fù)雜或目前業(yè)務(wù)簡單但將來有可能變得復(fù)雜的架構(gòu)，建議視具體情況來確定合理的架構(gòu)，不要為了微服務(wù)而去微服務(wù)。

2. REST API 是一個(gè)種輕量級通信方式，也有助于跨平臺(tái)調(diào)用，我們的做法往往是提供一個(gè)客戶端 SDK，目前已有大量的技術(shù)來快速實(shí)現(xiàn) REST SDK，比如 Spring RestTemplate，或 Retrofit。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:34)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“痞子韋森特”的評論

@黃勇?:您好，公司現(xiàn)在用的事Dubbo框架，這是微服務(wù)框架還是SOA？記得有些博客說微服務(wù)去中心化，那這個(gè)中心是不是就是Dubbo 里的注冊中心？

感謝您的提問！

1. Dubbo 從本質(zhì)上來講屬于微服務(wù)框架，它有服務(wù)注冊與發(fā)現(xiàn)，也有服務(wù)之間不同協(xié)議的通信，以及服務(wù)調(diào)用的監(jiān)控。而傳統(tǒng)的 SOA 更傾向于使用 ESB 這類總線的方式來實(shí)現(xiàn)服務(wù)的注冊與通信，可以把 ESB 看成是一個(gè)中心，因此相對微服務(wù)而言，傳統(tǒng) SOA 更加重量級一些。我認(rèn)為微服務(wù)是 SOA 的一種輕量級實(shí)現(xiàn)，它的本質(zhì)還是 SOA。

2. 所謂去中心化，實(shí)際上是確保不因?yàn)橹行亩鴮?dǎo)致單點(diǎn)故障，如果能解決這個(gè)問題，有中心又如何呢？因此，我認(rèn)為不要一味地去中心化，要合理地去中心化才是正道。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:27)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“ganqing”的評論

@黃勇?:?

1. 微服務(wù)業(yè)務(wù)拆分有沒有什么原則要點(diǎn)？

2.?如何簡單有效的實(shí)現(xiàn)事務(wù)？

3.?目前很火的容器技術(shù)和微服務(wù)如何結(jié)合？

請大俠講講。謝謝

感謝您的提問！

1. 微服務(wù)業(yè)務(wù)拆分可按整體業(yè)務(wù)組件來拆分，也可按單一業(yè)務(wù)功能來切分。建議切分步驟從粗到細(xì)，逐步細(xì)化，否則開始就過細(xì)，導(dǎo)致依賴性太高，增加復(fù)雜度。

2. 可使用消息隊(duì)列的方式，實(shí)現(xiàn)服務(wù)之間的事務(wù)控制。服務(wù)調(diào)用完畢，寫入消息隊(duì)列，通過消息驅(qū)動(dòng)的方式調(diào)用其他服務(wù)。

3. 由于微服務(wù)架構(gòu)是可以做到服務(wù)的異構(gòu)性的，也就是說，我們可根據(jù)實(shí)際情況，選擇最適合的開發(fā)語言來實(shí)現(xiàn)服務(wù)。容器技術(shù)具備隔離性，可將異構(gòu)開發(fā)語言的服務(wù)進(jìn)行統(tǒng)一封裝，并有助于自動(dòng)化部署，以及持續(xù)交付。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:19)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“noday”的評論

@黃勇?:什么樣的場景需要微服務(wù)？微服務(wù)比普通架構(gòu)需要多做那些工作？openstack的架構(gòu)設(shè)計(jì)屬于什么類型？微服務(wù)是不是需要更多的運(yùn)行資源？高并發(fā)低延遲的系統(tǒng)能使用微服務(wù)嗎？

感謝您的提問！

1. 我認(rèn)為在以下幾種情況下，可考慮使用微服務(wù)架構(gòu)：

• 應(yīng)用變得越來越大時(shí)
• 項(xiàng)目存在多種開發(fā)語言時(shí)
• 感覺到經(jīng)典架構(gòu)模式太重時(shí)
• 修改了一個(gè) bug 需要平滑升級時(shí)
• 想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時(shí)

2. 微服務(wù)架構(gòu)比傳統(tǒng)架構(gòu)更加依賴于對自動(dòng)化運(yùn)維的支持。

3. OpenStack 是一款云計(jì)算平臺(tái)，為云計(jì)算的 IaaS 層提供了解決方案。

4. 在微服務(wù)架構(gòu)中，需要相關(guān)的基礎(chǔ)設(shè)施與很多獨(dú)立運(yùn)行的服務(wù)，我認(rèn)為相比較傳統(tǒng)架構(gòu)而言，所消耗的硬件資源較高一些。但從現(xiàn)在來看，硬件資源的成本已經(jīng)非常低了。

5. 我認(rèn)為高并發(fā)場景不太適合使用微服務(wù)，因?yàn)槲⒎?wù)會(huì)帶來一些調(diào)用鏈的開銷，高并發(fā)場景需要做到盡可能地的延遲以及更高效的通訊。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:13)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“滔滔007”的評論

@黃勇?:?

權(quán)限分 訪問權(quán)限與資源權(quán)限

想請教下 資源權(quán)限在微服務(wù)中怎么做. ?比如我有個(gè)商品服務(wù) ?跟優(yōu)惠服務(wù) 想要控制某個(gè)用戶只能查詢商品和創(chuàng)建優(yōu)惠券 是每個(gè)微服務(wù)都有獨(dú)自的權(quán)限功能 還是有個(gè)權(quán)限服務(wù)統(tǒng)一下發(fā)和調(diào)配各個(gè)微服務(wù)的權(quán)限？或者貴公司在微服務(wù)中是怎么做權(quán)限這塊的？

感謝您的提問！

1. 訪問權(quán)限建議在服務(wù)網(wǎng)關(guān)處加以控制。
2. 資源權(quán)限建議抽象出一個(gè)單獨(dú)的中間件加以控制。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-18 10:53)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“曾經(jīng)的十字鎬”的評論

@黃勇?:勇哥我覺得接口調(diào)用次數(shù)統(tǒng)計(jì)，也可以結(jié)合flume + Mq + strom做實(shí)時(shí)統(tǒng)計(jì)，這樣可以根據(jù)日志信息獲取調(diào)用次數(shù)額外的東西，如調(diào)用者所在的地區(qū)等。

感謝您的提問！

看具體要求是怎樣的，如果只是簡單記錄 API 調(diào)用次數(shù)，可在服務(wù)網(wǎng)關(guān)處增加此功能，將結(jié)果記錄到 MQ 中。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-18 10:45)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“kevin”的評論

@黃勇?:微服務(wù)下有不同的存儲(chǔ)介質(zhì)，對于跨數(shù)據(jù)庫的分頁查詢有什么好的辦法嗎？謝謝@！

感謝您的提問！

使用微服務(wù)架構(gòu)可以做到：
1. 一個(gè)服務(wù)使用一個(gè)數(shù)據(jù)庫（單庫）
2. 一個(gè)服務(wù)使用多個(gè)數(shù)據(jù)庫（多庫）

對于“多庫”而言，可在服務(wù)內(nèi)部聚合數(shù)據(jù)，也可使用數(shù)據(jù)庫中間件來解決此問題。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-18 10:37)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“混元?dú)w一”的評論

@黃勇?:您好，我在公司實(shí)現(xiàn)分布式的過程中遇到了3個(gè)問題，如您有時(shí)間請您給些思路：

1.分布式事物：當(dāng)前采用消息隊(duì)列，隊(duì)列的消費(fèi)者使用redis做分布式鎖來實(shí)現(xiàn)冪等消費(fèi)，不知道這種方式存在什么隱患？或者有沒有更好的方式？

2.日志聚合：目前想要做一個(gè)日志聚合功能，暫時(shí)考慮還是使用消息隊(duì)列處理，不知道有什么業(yè)界成熟的方式？

3.方法調(diào)用次數(shù)統(tǒng)計(jì)，暫時(shí)我們想使用AOP+消息隊(duì)列+strom的方式來實(shí)現(xiàn)方法調(diào)用與耗時(shí)統(tǒng)計(jì)，不知道業(yè)界成熟的方式是什么？

希望您在百忙之中提供思路。謝謝

感謝您的提問！

1. 消息隊(duì)列可用于分布式事務(wù)控制，這項(xiàng)技術(shù)已經(jīng)在業(yè)界被證實(shí)是可用的。此外，還有 CQRS 與 Event Sourcing 技術(shù)也可以嘗試一下。

2. 日志聚合可使用業(yè)界流行的 ELK，即 Elasticsearch + Logstash + Kibana 來實(shí)現(xiàn)，L 用于收集日志，E 用于存儲(chǔ)日志，K 用于展現(xiàn)日志。

3. 方法調(diào)用次數(shù)統(tǒng)計(jì)，不建議放在服務(wù)內(nèi)部通過 AOP 來控制，建議在微服務(wù)架構(gòu)的服務(wù)網(wǎng)關(guān)（Service Gateway）加以控制。

--- 共有 1 條評論 ---

• 混元?dú)w一非常感謝您的回復(fù)。學(xué)習(xí)啦?(3個(gè)月前)??

評論(1)|?引用此答案|?舉報(bào)?(2016-10-18 10:26)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

引用來自“Mr成”的評論

@黃勇?:您好,

服務(wù)與服務(wù)之間的事務(wù)怎么做?

接口的調(diào)用權(quán)限如何控制,粒度在方法級別的

謝謝

感謝您的提問！

1. 在微服務(wù)架構(gòu)中，建議盡量避免服務(wù)之間的調(diào)用，因此服務(wù)粒度的切分是至關(guān)重要的；服務(wù)間的調(diào)用會(huì)產(chǎn)生分布式事務(wù)問題，建議采用“最終一致性”方法來確保分布式事務(wù)，業(yè)界有兩種常用做法：CQRS 和 Event Sourcing。

2. 此處所描述的“接口”是否理解為服務(wù)的 API 接口呢？API 調(diào)用的權(quán)限控制可在微服務(wù)架構(gòu)中的服務(wù)網(wǎng)關(guān)（Service Gateway）處加以控制。

評論(0)|?引用此答案|?舉報(bào)?(2016-10-18 10:14)

• 黃勇3個(gè)月前

  引用來自“waylau”的評論

  @黃勇?:SOA 與 MSA（微服務(wù)架構(gòu)）區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化（“微化”）的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍，服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
  )。但同時(shí)引入的一些問題：
  * 服務(wù)治理；
  * 服務(wù)的版本更新；
  * 服務(wù)之間的權(quán)限是如何來做控制的；
  * 服務(wù)如何來劃分顆粒度。
  
  黃老師，請教下，貴公司在實(shí)踐過程中，有無遇到過上述問題，是如何解決的？

  感謝您的提問！

  您說的非常好，這些問題可能都是每一位微服務(wù)實(shí)踐者所要面對的問題，考驗(yàn)我們的是，如何選擇合理的技術(shù)來解決此類問題。比如，服務(wù)治理可通過 Kubernetes、Mesos、Docker Swarm 等技術(shù)來實(shí)現(xiàn)，服務(wù)版本可通過 ZooKeeper、Etcd、Consul 等技術(shù)來控制，服務(wù)權(quán)限可自行實(shí)現(xiàn)權(quán)限中間件來解決，服務(wù)顆粒度劃分考驗(yàn)我們的是對業(yè)務(wù)的深度理解（這才是最為關(guān)鍵的）。總之，有具體技術(shù)能解決的可能都不是問題，可能是問題的往往是我們對自身業(yè)務(wù)的理解與把控能力。

  評論(0)|?引用此答案|?舉報(bào)?(2016-10-19 09:42)

總結(jié)

以上是生活随笔為你收集整理的OSC 第 130 期高手问答 — 究竟什么才是微服务？_黄勇【摘选】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。