【好書推薦】實踐“微服務(wù)”，你“玩得起”嗎？（獲獎名單已公布）

supergirlxu

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

xiaojun63

微服務(wù)，分開來就是微、服務(wù)。體現(xiàn)了粒子程度更小，構(gòu)建業(yè)務(wù)流程更靈活。就好比restful就行的原理一樣

jieforest

1. 你了解微服務(wù)嗎？SOA和微服務(wù)有何差異？
微服務(wù)架構(gòu)被認為是目前最適合開發(fā)高可擴展性應(yīng)用的架構(gòu)風(fēng)格，微服務(wù)架構(gòu)致力于解決大型、復(fù)雜的應(yīng)用的各種問題。它是一種基于服務(wù)的架構(gòu)，這些服務(wù)可獨立部署，作為基礎(chǔ)的組件。微服務(wù)架構(gòu)在整個開發(fā)、測試等開發(fā)周期中提供了更好的控制，但它在服務(wù)分類方面有一些限制。微服務(wù)架構(gòu)還使用了服務(wù)間的通信協(xié)議（REST、JSON等）。
SOA架構(gòu)可以由多種定義方式，這是因為SOA架構(gòu)風(fēng)格一直在不斷地發(fā)展演進。它為企業(yè)級軟件的復(fù)雜組合帶來了秩序——通過把它們表示為服務(wù)的集合。SOA還使用了服務(wù)通信協(xié)議，SOA可以被認為是微服務(wù)的超集。
SOA架構(gòu)依賴于共享數(shù)據(jù)模型。此模型在大量數(shù)據(jù)結(jié)構(gòu)和模型和分層之間有復(fù)雜的關(guān)系。SOA的分層組織結(jié)構(gòu)有利于服務(wù)協(xié)調(diào)和消息通信功能。
SOA是基于共享數(shù)據(jù)模型的，因此，可以預(yù)估它在服務(wù)和其它系統(tǒng)組件之間存在數(shù)據(jù)緊耦合的現(xiàn)象。這使得它難以做改變。一些附帶的重測是必要的，以確保改變不影響現(xiàn)有的任何服務(wù)。
微服務(wù)架構(gòu)存在上下文邊界的概念，這使得它在單個服務(wù)和數(shù)據(jù)之間存在關(guān)聯(lián)。
SOA架構(gòu)的多層模型以中央的消息通信中間件層為主要特征。而對于微服務(wù)架構(gòu)，在組成應(yīng)用的各種服務(wù)之上就存在一個非協(xié)調(diào)的API層。
通過一個中央集線控制器，SOA維護了服務(wù)執(zhí)行的順序。而微服務(wù)使用了服務(wù)間的通信協(xié)議來維護服務(wù)執(zhí)行的順序。
SOA架構(gòu)致力于解決在復(fù)雜的企業(yè)系統(tǒng)中的異構(gòu)應(yīng)用，促成跨應(yīng)用和功能的共享服務(wù)。而微服務(wù)架構(gòu)是面向基于Web的、更小的、不太復(fù)雜的應(yīng)用程序的最佳架構(gòu)方式，這些應(yīng)用程序不需要明確的服務(wù)協(xié)調(diào)。

2. 到底在什么樣的情況才適合使用微服務(wù)架構(gòu)？
如果遇到了以下的情況，應(yīng)該采用微服務(wù)架構(gòu)：
1）系統(tǒng)越來越龐大，新功能開發(fā)或修改功能變得越來越耗時
2）系統(tǒng)的復(fù)雜度極高，模塊間緊耦合嚴重，整體擴展性差
3）系統(tǒng)性能不高，通過擴展也難以提升性能
4）系統(tǒng)的可維護性越來越差

3. 服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級別的？
我通常是這么解決的。在基礎(chǔ)服務(wù)的上層封裝面向事務(wù)處理的服務(wù)（這里我稱為A服務(wù)），A服務(wù)依賴于下層的多個基礎(chǔ)服務(wù)，一個A服務(wù)就是一個完整的事務(wù)處理過程，它內(nèi)部是調(diào)用下層的多個服務(wù)共同完成功能的。如果A服務(wù)執(zhí)行失敗，則做相應(yīng)的回退等處理；如果A服務(wù)執(zhí)行成功，那么繼續(xù)。
微服務(wù)架構(gòu)的服務(wù)之間的調(diào)用，可以通過REST接口，還可以用RPC、消息通信等方式。以REST接口為例，服務(wù)間通過內(nèi)網(wǎng)或?qū)＞�方式進行調(diào)用，以保證速度。對外則使用API網(wǎng)關(guān)來做訪問控制。

4. 為什么有人說“玩不起”？較比普通架構(gòu)需要多做那些工作？
微服務(wù)架構(gòu)要設(shè)計好并不容易。我的建議是根據(jù)具體的需求具體分析，通用的原則也不少。

chenyx

還沒接觸到微服務(wù)呢,搬個板凳坐等討論

heguangwu

1、你了解微服務(wù)嗎？SOA和微服務(wù)有何差異？
     微服務(wù)實質(zhì)上就是SOA的一種實現(xiàn)方式，SOA是一個失敗的項目，所以微服務(wù)不想和他扯上關(guān)系
     微服務(wù)是一種基于服務(wù)(Service)的架構(gòu)，這些Service可獨立測試、部署、升級。微服務(wù)架構(gòu)為整個開發(fā)周期中提供了靈活的控制
2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)？
     業(yè)務(wù)清晰并可以被劃分成一個個獨立的service，service之間不需要復(fù)雜的相互調(diào)用關(guān)系
3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級別的
     服務(wù)之間是事務(wù)是指分布式事務(wù)嗎？怎么做取決于這類分布式事務(wù)是否很多，如果很少那就例外，如采用在某一個服務(wù)來做，如果很多那就可以采用分布式事務(wù)的做法，但通常都比較復(fù)雜，個人認為得不償失，還不如考慮這些服務(wù)不拆分
4、為什么有人說“玩不起”？較比普通架構(gòu)需要多做那些工作？
    最主要的性能不好把控，因為微服務(wù)是一個分布式架構(gòu)，運維和問題定位會復(fù)雜很多

forgaoqiang

1、你了解微服務(wù)嗎？SOA和微服務(wù)有何差異？最近國內(nèi)外技術(shù)論壇博客上微服務(wù)話題非常熱門，個人也讀過一些文章，對微服務(wù)也有些理解。
微服務(wù)架構(gòu)屬于應(yīng)用技術(shù)架構(gòu)，和B/S架構(gòu)類似。強調(diào)的是把復(fù)雜的“巨型單應(yīng)用”拆分成小的應(yīng)用，數(shù)據(jù)上也從集中存儲拆分為更小的存儲單元。
至于SOA是企業(yè)架構(gòu)的范疇，主要是把業(yè)務(wù)上分解為不同的服務(wù)，不同的物理系統(tǒng)提供不同的服務(wù)，注重的是系統(tǒng)之間通過服務(wù)進行互聯(lián)交互的規(guī)范，對于如何實現(xiàn)這些服務(wù)并沒有做規(guī)定。
因此個人理解是，SOA是更大一些的架構(gòu)規(guī)范，沒有規(guī)定具體實現(xiàn)，而微服務(wù)則是如何實現(xiàn)具體的業(yè)務(wù)，兩者并沒有直接關(guān)系。完全可以使用SOA實現(xiàn)企業(yè)服務(wù)，具體的服務(wù)則通過微服務(wù)的形式進行拆解。



2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)？
①首先，微服務(wù)架構(gòu)的應(yīng)用肯定是用在較大規(guī)模的服務(wù)上，規(guī)模大指的是業(yè)務(wù)發(fā)雜程度高。
②需要經(jīng)常進行升級修改的服務(wù)，對于多年不需要變化的服務(wù)沒有必要進行拆分。
③系統(tǒng)越來越龐大，啟動速度過慢，無法進行維護。
④不同服務(wù)根據(jù)實際需求需要采用不同的技術(shù)實現(xiàn)（甚至是不同語言實現(xiàn)）的時候。



3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級別的？
為了保證數(shù)據(jù)的一致性，事務(wù)是不可避免要上的，每個服務(wù)都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界。服務(wù)之間的通信和Java的ESB不同，微服務(wù)應(yīng)用采用簡單輕量級協(xié)議，比如REST，而不是WS-，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能。微服務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。
每個服務(wù)都根據(jù)內(nèi)部處理情況返回結(jié)果，服務(wù)仍然需要分層，一旦底層服務(wù)調(diào)用失敗，要有對應(yīng)的異常處理機制。至于權(quán)限控制，目前來看不可避免的需要在每次調(diào)用的是有帶上token憑據(jù)，微信公共號開發(fā)就是類似的原理，保證權(quán)限控制，粒度應(yīng)該在每次調(diào)用都需要進行檢查。



4、為什么有人說“玩不起”？較比普通架構(gòu)需要多做那些工作？

這個的確會增加復(fù)雜度，首先整個系統(tǒng)是分布式的，而且數(shù)據(jù)存儲也是分離的，即使根據(jù)CAP原理，要保證數(shù)據(jù)的一致性也會變得更加困難，比如有以下的難題：
①服務(wù)因為是分布式的，業(yè)務(wù)調(diào)試難度增加，溝通成本顯著增加。
②微服務(wù)架構(gòu)模式應(yīng)用的改變會波及多個服務(wù)，特別是服務(wù)之間有依賴的情況，需要協(xié)調(diào)多服務(wù)變更。
③每個服務(wù)都有自己的實例，運行狀態(tài)，需要分別配置、部署、監(jiān)控，還要實現(xiàn)服務(wù)的發(fā)現(xiàn)機制，目前視乎不像SOA那樣有成熟的服務(wù)發(fā)現(xiàn)機制。


以前看過一篇文章說明比如構(gòu)建一個滴滴打車或者Uber一樣的應(yīng)用，提出了傳統(tǒng)和微服務(wù)的兩種架構(gòu)，感覺不錯，的確可以參考：

①這個是傳統(tǒng)的單應(yīng)用架構(gòu)，核心是業(yè)務(wù)邏輯

下面是微服務(wù)方式實現(xiàn)的，每一個應(yīng)用功能區(qū)都使用微服務(wù)完成，另外，Web應(yīng)用會被拆分成一系列簡單的Web應(yīng)用

chenxing2

1、你了解微服務(wù)嗎？SOA和微服務(wù)有何差異？

    SOA：面向服務(wù)的架構(gòu)，ESB是其一種實現(xiàn)，就是要將緊耦合的系統(tǒng)，劃分為面向業(yè)務(wù)的，粗粒度，松耦合，無狀態(tài)的服務(wù)。服務(wù)發(fā)布出來供其他服務(wù)調(diào)用，一組互相依賴的服務(wù)就構(gòu)成了SOA架構(gòu)下的系統(tǒng)。
    微服務(wù)：是隨著互聯(lián)網(wǎng)的興起而出現(xiàn)的，互聯(lián)網(wǎng)主要就是快速迭代，對于SOA這樣重的系統(tǒng)，迭代一次是很痛苦的，完全達不到互聯(lián)網(wǎng)時代的要求，所以將一些獨立的服務(wù)抽取出來，做一個小型的服務(wù)（微服務(wù)），方便快速迭代，即使出問題，也不會影響不相關(guān)的服務(wù)，根據(jù)各自服務(wù)的特性可以選擇最佳的編程語言來實現(xiàn)。

2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)？

    最最合適的情況是，不依賴其他服務(wù)而又能對外提供服務(wù)，且又不涉及事物問題
   
3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級別的？

服務(wù)與服務(wù)之間都是獨立的，不可能跟傳統(tǒng)寫法一樣，在一個大事物中處理。
傳統(tǒng)做法使用 分布式事物XA 兩階段提交，但性能會較差些，一般互聯(lián)網(wǎng)公司很少使用這種方式
一般使用最終一致，即通過后續(xù)補償保證數(shù)據(jù)的一致性。
在服務(wù)拆分或設(shè)計時就要盡量避免這種情況出現(xiàn)。

服務(wù)的調(diào)用通常不會暴露到公網(wǎng)，都是內(nèi)網(wǎng)調(diào)用，不必限制到方法，通過ssl或ip控制即可
一般接入層涉及訪問控制，通常使用spring security或apache shiro來控制資源的訪問

4、為什么有人說“玩不起”？較比普通架構(gòu)需要多做那些工作？

玩不起是因為后期微服務(wù)會變得復(fù)雜，
要多做的工作：服務(wù)注冊與發(fā)現(xiàn)、熔斷恢復(fù)、黑白名單、超時控制、服務(wù)容錯、灰度路由、鏈路追蹤、容量規(guī)劃、
實時監(jiān)控、流量控制、服務(wù)降級、冪等保障以及分庫分表、事物等等

cxsvip

高大上的話題，不了解

Fl_wolf

微服務(wù)這東西還真不是很懂 0 0。。 我就來支持楠子一下。。 繼續(xù)看其他書去了。。

laputa73

正在關(guān)注這個問題。
我覺得soa和微服務(wù)思路上沒有本質(zhì)區(qū)別，主要是領(lǐng)域問題，一個是對外，關(guān)注共享， 一個是對內(nèi)，關(guān)注通信。
二者在管理需求上有較大差異。
再就是度的問題，soa開放的接口數(shù)量遠比微服務(wù)小，量變到質(zhì)變。
微服務(wù)和corba其實有點象。