OSC 第 130 期高手问答 — 究竟什么才是微服务？_黄勇【摘选】
?OSC 第 130 期高手問答 — 究竟什么才是微服務？
url：https://www.oschina.net/question/2720166_2201257
本文截取自“OSCHINA 本期高手問答(10 月 17 日-10 月 23 日) 我們請來了@黃勇為大家解答關于微服務架構方面的問題。”
引用來自“sofn”的評論
@黃勇?: 聽說微服務是個很大的概念，Dubbo只是實現了其中一小部分，請問完善的微服務架構是什么樣的？Spring Cloud是否算是完善的微服務？
感謝您的提問！
微服務架構的范圍比較大，Dubbo 和 Spring Cloud 都只是解決了微服務的一部分問題，并未完全覆蓋。稍后我也出一篇文章，將上周去 QCon 分享的微服務架構，給大家再次做一個介紹。
引用來自“祥子-匠心”的評論
@黃勇?微服務的開源技術選型能介紹幾種嗎？Spring Cloud如何解決跨語言的問題呢感謝您的提問！
比較知名的微服務開源技術選型莫過于 Spring Cloud，它對 Netflix 提供的相關組件做了一定的封裝，讓開發者更容易上手。當然，我更加希望本書所先介紹的開源技術選型會被更多人接受與應用。
引用來自“p2ng”的評論
@黃勇?:如何更好理解【微服務】這個“微”字。從設計之初，開發，部署，運維，監控，等有什么地方（基于你的過往歷程）需要關注的感謝您的提問！
我認為「微」并非它的體積足夠小，而是它的責任足夠單一，很多人誤解了「微」的真實含義，認為服務拆分得足夠小就是微服務了，其實并非這樣。此外，「微」還有“微不足道”的意思，也就是說，某個服務出現故障，它不會影響整個系統。
引用來自“Yuhoo2013”的評論
@黃勇?: 微服務拆分如果粒度太細，會不會導致維護成本增加？響應時間增加？事務控制如何實現？感謝您的提問！
1. 微服務粒度問題取決于我們對業務的理解與把控能力，無需太細。
2. 可借用消息隊列和日志追蹤進行事務控制，也可使用CQRS 或 Event Sourcing 解決方案。
引用來自“西夏一品堂”的評論
@黃勇?: ?目前，微服務的事務是大家最關系的？請問，現在業界有沒有開源的解決微服務事務的項目感謝您的提問！
微服務的事務控制比較復雜，我們需要做到盡可能避免服務之間的調用，這取決于我們對微服務切分的粒度控制。業界有 CQRS 與 Event Sourcing 來解決微服務的事務問題，希望對您有幫助。
引用來自“歸園田居”的評論
@黃勇?:微服務具體應用于哪些場景？感謝您的提問！
我認為在以下幾種情況下，可考慮使用微服務架構：
- 應用變得越來越大時
- 項目存在多種開發語言時
- 感覺到經典架構模式太重時
- 修改了一個 bug 需要平滑升級時
- 想對系統進行細粒度監控時
引用來自“羅厚付”的評論
@黃勇?微服務框架是在Soa的基礎上提出的嗎？在技術選型要注意哪些點，用spring cloud還是spring boot?怎樣做到輕量級，有哪些參考？感謝您的提問！
1. 我認為微服務是傳統 SOA 的輕量級解決方案，它讓 SOA 更加容易落地。
2. 在微服務技術選型方面，我建議竟可能地輕量級，做到“進可攻退可守”，至于 Spring Cloud 還是其他框架，完全取決于我們對技術本身的理解以及對業務的把控能力，技術也業務需要相互結合才能產生價值。
3. 希望這本書中所設計的輕量級開源方案，會幫助您更快地搭建微服務架構。
-
引用來自“機器貓123”的評論
@黃勇?老師你好，才看到osc請你來做問答，很高興。從上次你的《架構探險：從零開始寫Java Web框架》的問答，我就很關注你。還買了你的這本書，很受用。這次你的這本關于輕量級微服務，我有幾個問題，你的這本書里關于微服務的技術選型是怎么考量的？書中提到了spring boot，你對與spring的這個技術怎么看？微服務的應用場景大部分是什么？現在微信小程序比較流行，微服務會成為小程序的技術首選嗎？感謝您的提問！
1. 這本書中關于微服務的技術選型問題，我做了大量的思考并實踐，所選擇的方案均為開源，且非常輕量級，目的是幫助大家能夠快速搭建這款輕量級微服務架構。
2. 雖然這本書講到的微服務開發框架是 Spring Boot，用過的人都知道它有明顯的優勢，當然也有明顯的劣勢，畢竟底層還是基于 Spring，而 Spring 從當初的輕量級似乎變得越來越重，我希望有更好的輕量級框架可以出現，所以當初寫了一款 Smart 框架以及《架構探險》第一本書，目的只是拋磚引玉，希望有更多的朋友都能投身到國內開源行業中，創造更優秀的開源項目。
3. 我非常看好微信小程序的未來，但微服務是否成為小程序的技術首選，我不太敢下次評論，咱們一起靜觀其變吧。
--- 共有 1 條評論 ---- 機器貓123謝謝黃老師。?(3個月前)??
-
引用來自“風箏上的少年”的評論
@黃勇?:微服務怎么解決調用鏈過長導致的調試或異常追蹤過難的問題呢？感謝您的提問！
調用鏈追蹤是微服務落地的一個挑戰，我們一般通過追蹤平臺來解決，推薦使用開源的 Zipkin。
引用來自“飛天蘿卜”的評論
@黃勇?:微服務目前有什么成熟的一整套開源方案嗎？包括測試、版本控制，發布流程，代碼錯誤回滾？感謝您的提問！
業界也有其他優秀的微服務開源方案，例如 Java 領域的 Netflix 與 Spring Cloud。當然，我更希望本書所提到的開源方案，可以被更多人接受并應用。
引用來自“lqjava”的評論
@黃勇?:微服務是否就一定是進程級別的？在同一個進程內實現微服務可行嗎？如果一個服務就一個進程，這樣是不是會耗費大量系統資源？
感謝您的提問！
1. 微服務講究的是服務可以獨立開發與部署，如果在進程內進行微服務，將帶來很高的復雜度，就像當年的 OSGi 那樣，理念非常好，但實踐起來卻困難重重。
2. 一個服務一個進程，這樣讓服務的隔離性更加徹底，配合 Docker 容器技術，可以更加高效低利用服務器硬件與網絡資源。
-
引用來自“Rwing”的評論
@黃勇?:請問微服務的核心系統是什么？是微服務的發現和組織嗎？每個微服務很好做，如何把他們組合起來是不是有現成的系統可以參考、感謝您的提問！
1. 我認為微服務的核心是：服務注冊中心（Service Registry）與服務網關（Service Gateway），它們配合完成服務注冊與服務發現。
2. 將服務組合起來也成為“服務編排”，有多重做法，可以在服務網關中進行編排，也可以通過中間服務進行編排，我更傾向于后者，這樣確保服務網關不包含任何業務，更加輕量級。
-
引用來自“zcfrank1st”的評論
@黃勇?:微服務的分布式事務問題如何解決？一般拆分服務的原則？謝謝！
感謝您的提問！
1. 微服務分布式事務一般借助消息驅動與日志追蹤的方式來解決，以達成事務的“最終一致性”，當然市面上也有 CQRS 與 Event Sourcing 解決方案。
2. 微服務拆分原則取決于我們對業務的理解與把控能力。
引用來自“empireghost”的評論
@黃勇?: 微服務都是通過HTTP方式對外提供？感謝您的提問！
微服務對外的接口不一定局限于 HTTP 或 HTTPS，也可以是 TCP，需要根據具體情況而定。
引用來自“idisikx”的評論
@黃勇?:SOA WebService RESTFul 這些概念有啥本質的區別。開發者平常使用的那些ajax http接口（含session狀態的）算的上restful接口嗎？感謝您的提問！
1. RESTful 是一種架構風格，SOA 是一種架構思想，可以認為 RESTful 有助于 SOA 的落地化。
2. RESTful 一般應用在 HTTP 協議上，在前后端分離架構中，前端通過 AJAX 技術發送 RESTful HTTP 請求到后端，獲取后端 JSON 數據，并進行界面渲染。同樣，RESTful 也用于微服務架構中，每個服務對外暴露 REST API 作為通信接口。
引用來自“Albert-Liu”的評論
@黃勇?:怎樣來控制微服務的粒度？
就是有沒有什么樣的原則和最佳實踐來判斷一個功能（接口）是應該屬于A服務還是應該屬于B服務。
另外，是否有接觸過“領域驅動的分析與設計方法(DDD)”，你是如何理解“DDD ”與“微服務”之間關系的？
感謝您的提問！
1. 微服務的粒度控制取決于我們對業務的理解與把控能力，一切所謂的原則都是不靠譜的。
2. DDD 是基于領域對象的設計思想，微服務是基于服務的業務架構，DDD 與微服務可相輔相成。
引用來自“大哈ha”的評論
@黃勇?:可以問下，目前有哪些大公司，大項目在使用微服務架構嗎？感謝您的提問！
國外的 Google、Amazon、Netflix 等都在使用微服務架構，國內也開始有互聯網與軟件公司在使用微服務架構。
引用來自“阿里巴巴廁所所長”的評論
@黃勇?:Docker容器技術的出現，為微服務提供了更便利的條件，比如更小的部署單元，每個服務可以通過類似Node.js或Spring Boot的技術跑在自己的進程中。可能在幾十臺計算機中運行成千上萬個Docker容器，這么多Docker容器怎么來有效管理？出錯了如何排查呢？感謝您的提問！
實際上您提到的是服務治理問題，目前有大量的技術可以做到，比如：Google Kubernetes、Apache Mesos、Docker Swarm 等。
引用來自“imlzw”的評論
@黃勇?:針對微服務的全局id生成策略。不知道黃老師有沒有什么好的建議？
1.看了很多的分布式id生成策略。提到很多id趨勢遞增的策略，這個有什么用？
2.為什么要讓id具體有順序功能？如何保證順序？
不知道黃老師在實際項目中用了什么策略，希望能分享一下。
感謝您的提問！
實際上 ID 生成策略并非是微服務架構所涵蓋的范疇。我認為比較好的 ID 生成策略需要結合您所面臨的實際需求，一般應用場景下，可通過 Redis 來生成并管理 ID，它具備較高的并發能力，且能確保分布式一致性。
引用來自“蘿卜K”的評論
@黃勇?:微服務挺多人說玩不起，是不是相對來說實施成本挺高的？感謝您的提問！
玩不起包括兩層含義：一是認為成本較高；二是擔心有風險（怕玩掛了）。
引用來自“Elven_Xu”的評論
@黃勇?:我們是小公司，業務比較簡單，系統也不是很大，請問是否適合微服務？微服務適用于哪些場景？感謝您的提問！
我認為在以下幾種情況下，可考慮使用微服務架構：
- 應用變得越來越大時
- 項目存在多種開發語言時
- 感覺到經典架構模式太重時
- 修改了一個 bug 需要平滑升級時
- 想對系統進行細粒度監控時
當然還有其他使用場景，但微服務不是萬靈丹，不能適用于所有場景。
業務目前比較簡單，但將來會變得復雜，也建議使用微服務架構。
引用來自“owzander”的評論
@黃勇?:服務間是不是應該避免相互間調用, 由API Gateway來組織各個服務？感謝您的提問！
沒錯，應該避免服務間的調用，而使用服務網關作為調用入口，但我不建議在服務網關處組織服務調用，而是通過一個中間服務來編排，或使用消息驅動方式來完成。
引用來自“wj2699”的評論
@黃勇?:該在多大規模的項目中使用微服務比較合適？微服務會增加架構復雜度嗎？帶來的收益是否可以抵消？感謝您的提問！
1. 我認為對于業務比較清晰的項目均可使用微服務架構，并非需要具備多大規模。
2. 微服務架構會帶來系統的復雜度（成本），但必然會帶來一些收益，至于成本和收益是否低效，這取決于我們對微服務與業務的理解與把控能力。
-
引用來自“逝影落楓”的評論
@黃勇?:實施微服務后，對于開發成本是不是更高了？感謝您的提問！
我認為實施微服務并未提高開發成本，而是提高運維成本，一個好的微服務架構離不開運維方面的支持。本書下冊將針對運維方面將以描述，敬請期待。
-
引用來自“tom”的評論
@黃勇?:聽朋友說：使用docker運行java一點優勢都沒有，微服務架構，大量啟動docker集群，內存利用率很低，特亮瞎眼，雖然java運行效率很高
您怎么看？
感謝您的提問！
Java 應用經 Docker 化后，最明顯的問題是 Docker 鏡像體積較大，啟動 Docker 容器所占用的系統資源較高。建議根據實際業務場景，選擇最為合適的開發語言實現對應的微服務，而并非局限于 Java 應用之上。
-
引用來自“蘿卜Robert”的評論
@黃勇?:微服務架構我覺得比較適合新項目，如果已有項目那相當于要重構，或者逐步拆分做微服務架構？是不是這樣？還是有啥更好的方法？感謝您的提問！
1. 對于業務流程較為復雜，且業務會變得逐漸復雜的項目，可以考慮使用微服務架構。
2. 對于已有項目而言，可考慮逐步進行微服務化，也可考慮在新業務中使用微服務架構。
引用來自“Jayking001”的評論
@黃勇?:微服務比較適合在那些應用場景使用，還是說所有的應用服務，都做成微服務都好，微服務在事務控制方面，容錯方面有啥較好的實踐方式？感謝您的提問！
1. 我認為在以下幾種情況下，可考慮使用微服務架構：
- 應用變得越來越大時
- 項目存在多種開發語言時
- 感覺到經典架構模式太重時
- 修改了一個 bug 需要平滑升級時
- 想對系統進行細粒度監控時
當然還有其他使用場景，但微服務不是萬靈丹，不能適用于所有場景。
2. 微服務的事務控制本質上是分布式事務控制，建議使用“最終一致性”來確保。
3. 在容錯方面，需要有基礎設施平臺的支撐，比如服務網關的熔斷機制。
引用來自“德古拉-大貓”的評論
@黃勇?:從什么角度能區分出 或者劃分 微服務 和PRC分布式 之間的區別或者關系？感謝您的提問！
微服務是一種應用架構模式，而 RPC 是一種遠程調用方式，它們是不一樣的概念；而在微服務中會出現服務之間的調用，為了確保性能，我們一般采用 RPC 來調用。
引用來自“OSC首席醬油黨”的評論
@黃勇?:1.微服務粒度如何拆分；2.微服務對網絡、數據庫連接、緩存服務器等資源的影響；3：微服務是否需要多版本服務共存。謝謝回答！
感謝您的提問！
1. 微服務粒度的拆分取決于我們對業務的理解與把控能力。
2. 微服務對網絡、數據庫、緩存方面較傳統架構而言，沒有過高的要求，但對運維方面要求較高。
3. 微服務需要考慮服務多版本問題，尤其是服務升級時，需要做到平滑，對整體系統沒有任何影響。
引用來自“jeffsui”的評論
@黃勇?: 你好！我也有一個關于測試的問題想請教。
是不是微服務更偏重敏捷模式呢？對于測試而言更容易開展工作？自動化測試覆蓋率更高？
望不吝賜教。
感謝您的提問！
1. 我認為微服務與敏捷沒有必然的關系，微服務講究的是將“化整為零”，敏捷倡導的是“小步快跑”，但兩者可以有效地結合起來加以應用。
2. 較傳統架構而言，微服務的測試復雜度和覆蓋面將更為廣泛，不僅需要對每個服務進行測試，而且需要對整體應用加以驗證。因此，我們需要使用自動化測試技術來提高測試效率。
--- 共有 1 條評論 ---- jeffsui謝謝您的解答,這么看,對于測試的要求更高了。需要掌握自動化測試工具和不同框架的測試技術。?(3個月前)??
引用來自“wongloong”的評論
@黃勇?:請問：
1.微服務一般是json格式調用，與其他調用方式有什么區別么？
2.微服務使用場景是什么樣的？并不是所有的項目都要上微服務吧？微服務是把壓力轉向到運維是么？
3.具體微服務拆分力度。如果不使用docker，會給微服務帶來哪些不便
謝謝！
感謝您的提問！
1. 我認為 JSON 格式只是 REST API 返回值的一種，微服務并非局限于 REST API 通信。
2.?我認為在以下幾種情況下，可考慮使用微服務架構：
- 應用變得越來越大時
- 項目存在多種開發語言時
- 感覺到經典架構模式太重時
- 修改了一個 bug 需要平滑升級時
- 想對系統進行細粒度監控時
當然還有其他使用場景，但微服務不是萬靈丹，不能適用于所有場景。微服務對運維是有一定的要求的，尤其是自動化運維。
3. 微服務切分粒度完全基于我們對自身業務的理解與把控能力。如果沒有 Docker 這類容器技術，可能會降低微服務的部署與交付能力。
引用來自“西夏一品堂”的評論
@黃勇?: ?一個大服務怎么拆最好，依據是什么，拆分力度怎么控制？感謝您的提問！
建議從整個業務流程來分析，首先抽象出公共服務，然后采用大粒度的方式來切分，最后逐步細化切分粒度，這一切都基于對業務的理解與把控能力。
引用來自“平西王”的評論
@黃勇?: 請問，服務拆分之后，就會出現，微服務調用微服務的情況，導致效率很慢，接口的QPS很低，怎么解決？感謝您的提問！
我的建議是，盡可能避免服務之間的調用，不妨使用消息隊列的方式來降低服務之間的耦合，當然必要的直接調用可使用 RPC 技術，它具備優秀的性能，可確保較高的 QPS。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“子矜”的評論
@黃勇?: 我想利用微服務實現系統的模塊化，便于公共模塊復用和水平擴展，但目前的系統規模其實都很小，這種情況是不是不適合使用微服務？另外，使用REST通信其實挺麻煩的，還需要封裝一層調用方法，不知道有沒有類似的問題？感謝您的提問！
1. 我認為微服務架構用于業務較復雜或目前業務簡單但將來有可能變得復雜的架構，建議視具體情況來確定合理的架構，不要為了微服務而去微服務。
2. REST API 是一個種輕量級通信方式，也有助于跨平臺調用，我們的做法往往是提供一個客戶端 SDK，目前已有大量的技術來快速實現 REST SDK，比如 Spring RestTemplate，或 Retrofit。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“痞子韋森特”的評論
@黃勇?:您好，公司現在用的事Dubbo框架，這是微服務框架還是SOA？記得有些博客說微服務去中心化，那這個中心是不是就是Dubbo 里的注冊中心？感謝您的提問！
1. Dubbo 從本質上來講屬于微服務框架，它有服務注冊與發現，也有服務之間不同協議的通信，以及服務調用的監控。而傳統的 SOA 更傾向于使用 ESB 這類總線的方式來實現服務的注冊與通信，可以把 ESB 看成是一個中心，因此相對微服務而言，傳統 SOA 更加重量級一些。我認為微服務是 SOA 的一種輕量級實現，它的本質還是 SOA。
2. 所謂去中心化，實際上是確保不因為中心而導致單點故障，如果能解決這個問題，有中心又如何呢？因此，我認為不要一味地去中心化，要合理地去中心化才是正道。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“ganqing”的評論
@黃勇?:?
1. 微服務業務拆分有沒有什么原則要點？
2.?如何簡單有效的實現事務？
3.?目前很火的容器技術和微服務如何結合？
請大俠講講。謝謝
感謝您的提問！
1. 微服務業務拆分可按整體業務組件來拆分，也可按單一業務功能來切分。建議切分步驟從粗到細，逐步細化，否則開始就過細，導致依賴性太高，增加復雜度。
2. 可使用消息隊列的方式，實現服務之間的事務控制。服務調用完畢，寫入消息隊列，通過消息驅動的方式調用其他服務。
3. 由于微服務架構是可以做到服務的異構性的，也就是說，我們可根據實際情況，選擇最適合的開發語言來實現服務。容器技術具備隔離性，可將異構開發語言的服務進行統一封裝，并有助于自動化部署，以及持續交付。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“noday”的評論
@黃勇?:什么樣的場景需要微服務？微服務比普通架構需要多做那些工作？openstack的架構設計屬于什么類型？微服務是不是需要更多的運行資源？高并發低延遲的系統能使用微服務嗎？感謝您的提問！
1. 我認為在以下幾種情況下，可考慮使用微服務架構：
- 應用變得越來越大時
- 項目存在多種開發語言時
- 感覺到經典架構模式太重時
- 修改了一個 bug 需要平滑升級時
- 想對系統進行細粒度監控時
2. 微服務架構比傳統架構更加依賴于對自動化運維的支持。
3. OpenStack 是一款云計算平臺，為云計算的 IaaS 層提供了解決方案。
4. 在微服務架構中，需要相關的基礎設施與很多獨立運行的服務，我認為相比較傳統架構而言，所消耗的硬件資源較高一些。但從現在來看，硬件資源的成本已經非常低了。
5. 我認為高并發場景不太適合使用微服務，因為微服務會帶來一些調用鏈的開銷，高并發場景需要做到盡可能地的延遲以及更高效的通訊。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“滔滔007”的評論
@黃勇?:?
權限分 訪問權限與資源權限
想請教下 資源權限在微服務中怎么做. ?比如我有個商品服務 ?跟優惠服務 想要控制某個用戶只能查詢商品和創建優惠券 是每個微服務都有獨自的權限功能 還是有個權限服務統一下發和調配各個微服務的權限？或者貴公司在微服務中是怎么做權限這塊的？
感謝您的提問！
1. 訪問權限建議在服務網關處加以控制。
2. 資源權限建議抽象出一個單獨的中間件加以控制。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“曾經的十字鎬”的評論
@黃勇?:勇哥我覺得接口調用次數統計，也可以結合flume + Mq + strom做實時統計，這樣可以根據日志信息獲取調用次數額外的東西，如調用者所在的地區等。感謝您的提問！
看具體要求是怎樣的，如果只是簡單記錄 API 調用次數，可在服務網關處增加此功能，將結果記錄到 MQ 中。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“kevin”的評論
@黃勇?:微服務下有不同的存儲介質，對于跨數據庫的分頁查詢有什么好的辦法嗎？謝謝@！感謝您的提問！
使用微服務架構可以做到：
1. 一個服務使用一個數據庫（單庫）
2. 一個服務使用多個數據庫（多庫）
對于“多庫”而言，可在服務內部聚合數據，也可使用數據庫中間件來解決此問題。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“混元歸一”的評論
@黃勇?:您好，我在公司實現分布式的過程中遇到了3個問題，如您有時間請您給些思路：
1.分布式事物：當前采用消息隊列，隊列的消費者使用redis做分布式鎖來實現冪等消費，不知道這種方式存在什么隱患？或者有沒有更好的方式？
2.日志聚合：目前想要做一個日志聚合功能，暫時考慮還是使用消息隊列處理，不知道有什么業界成熟的方式？
3.方法調用次數統計，暫時我們想使用AOP+消息隊列+strom的方式來實現方法調用與耗時統計，不知道業界成熟的方式是什么？
希望您在百忙之中提供思路。謝謝
感謝您的提問！
1. 消息隊列可用于分布式事務控制，這項技術已經在業界被證實是可用的。此外，還有 CQRS 與 Event Sourcing 技術也可以嘗試一下。
2. 日志聚合可使用業界流行的 ELK，即 Elasticsearch + Logstash + Kibana 來實現，L 用于收集日志，E 用于存儲日志，K 用于展現日志。
3. 方法調用次數統計，不建議放在服務內部通過 AOP 來控制，建議在微服務架構的服務網關（Service Gateway）加以控制。
--- 共有 1 條評論 ---- 混元歸一非常感謝您的回復。學習啦?(3個月前)??
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
引用來自“Mr成”的評論
@黃勇?:您好,
謝謝
感謝您的提問！
1. 在微服務架構中，建議盡量避免服務之間的調用，因此服務粒度的切分是至關重要的；服務間的調用會產生分布式事務問題，建議采用“最終一致性”方法來確保分布式事務，業界有兩種常用做法：CQRS 和 Event Sourcing。
2. 此處所描述的“接口”是否理解為服務的 API 接口呢？API 調用的權限控制可在微服務架構中的服務網關（Service Gateway）處加以控制。
- 黃勇3個月前
引用來自“waylau”的評論
@黃勇?:SOA 與 MSA（微服務架構）區別在于系統一體化與服務組件分散化（“微化”）的區別。服務組件微化可以讓關注點進一步縮小范圍，服務之間的規范或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時引入的一些問題：
* 服務治理；
* 服務的版本更新；
* 服務之間的權限是如何來做控制的；
* 服務如何來劃分顆粒度。
黃老師，請教下，貴公司在實踐過程中，有無遇到過上述問題，是如何解決的？感謝您的提問！
您說的非常好，這些問題可能都是每一位微服務實踐者所要面對的問題，考驗我們的是，如何選擇合理的技術來解決此類問題。比如，服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現，服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制，服務權限可自行實現權限中間件來解決，服務顆粒度劃分考驗我們的是對業務的深度理解（這才是最為關鍵的）。總之，有具體技術能解決的可能都不是問題，可能是問題的往往是我們對自身業務的理解與把控能力。
總結
以上是生活随笔為你收集整理的OSC 第 130 期高手问答 — 究竟什么才是微服务？_黄勇【摘选】的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Aptana工具介绍
- 下一篇： Linux的PS1美化