過去的幾年來，「微服務」這個術語逐漸得到關注，它描述的是由一系列更小的服務所組成的架構。在qcon san francisco 2012上，thoughworks的james lewis針對這個概念發表了演講，同時還就這個話題與martin fowler合作撰寫了一篇文章。最近，steve jones加入了討論，他認為微服務並不是大家所認為的那樣，是什麼新東西，而只是soa的另乙個叫法。為了證明這一點，他對微服務目前的定義和oasis soa參考模型進行了對比。他遵循了james和martin在他們的文章中所列出的要點：\
面向服務架構（service oriented architecture，soa）這個范型是用來組織和使用分布式能力（capability）的，這些能力可能由不同所有者的域來進行控制。\
steve指出：\
根據oasis可以得出wtf實際上也是一種服務， \\在soa中，按照服務的機制，可以將需求和能力組織在一起。
在這個話題上，steve對比了martin/james的說法：\
服務是程序外的元件，它與元件明確的介面進行互動\
圍繞業務能力進行組織：這是steve認為martin產生誤解的地方，並且相信微服務並不是新的東西。oasis soa參考模型將能力（capability）定義為：\
服務提供者所能夠提供給服務消費者的一種真實的效果。\
steve指出區分能力（誰做這項任務）與服務（組織化的結構）是非常重要的。\
在過去的十多年間，我們在第一線實踐soa，與oasis soa rm這些富有經驗的人的共同發現就是\組織化的框架（organising framework）與行為本身是分離的。至關重要的原因就是人們在開始制定服務的時候通常將服務等同於能力（service = capability），這樣最終你會有很多很多的服務（如果刻薄一點的話，我可能就會將其稱之為微服務了）。
他認為儘管在這個話題上martin的說法是可以的，但是並沒有參考過去的重要材料。\
這是新鮮的事物嗎？我甚至編寫過\一本書來闡述如何圍繞這種方式建模、管理和組建團隊。
soa manifesto（2009）討論了soa背後的關鍵理念（儘管我還是更欣賞rm），這是由大量的實踐者做出的。這裡有兩個問題，第一就是混淆了服務與能力，第二是在管理方面沒有充分識別層級（hierarchies）的重要性。
基於產品而不是專案（products not projects）：steve說在這個話題上martin和james的文章比soa rm介紹的更深入，但是依然沒有什麼新鮮的東西。\
在google上快速搜尋一下就能看到在這個問題上已經有了很多的材料，有一些材料比其他的更好，也有一些更棒的產品，但是在這方面的確沒有什麼新鮮的。我曾經使用過這樣乙個術語「關注程式而不是專案（programs not projects）」，並且經常會談及將完整的生命週期分派給架構師，從而「使其更加具有責任感」。同樣，這種說法完全沒有錯誤，而是沒有什麼新意。多年以來我們就已經知道這會有所幫助，但是它有乙個很明顯的問題：成本。\
智慧型端點與啞管道（smart endpoints and dumb pipes）：steve完全同意這一原則，但他同樣認為這並沒有什麼新意。他的說法略微有些不同：\
在oasis soa rm中有乙個「執行上下文（execution context）」的概念。這是服務被呼叫及其能力被觸發的地方。顯然，端點是「智慧型的」，因為它是用來完成工作的，因此上文中用到了「\機制（mechanism）」這個詞。「通道」可能是也可能不是啞的（我認為與火星上的漫遊者進行對話「通道」是相當智慧型的），但它們是什麼
並沒有什麼價值。這是在soa中的一項重要發現，並且在soa rm進行了很好的記錄。執行上下文是所有內部任務完成的地方，但服務提供了訪問能力的入口，能力是交付價值的所在。
去中心化的治理（decentralized governance）：在有些方面，steve同意martin和james的觀點，但是……\
我認為這是乙個好的建議，在管理方面，soa比微服務做的更好。正如oasis soa rm所述， soa允許將這些理念應用到所有的it資產上，而不僅僅是根據特定風格實現的資產，事實上，僅僅考慮it資產是商業課程上就講授過的方式。\
微服務與soa：在開始的時候，james和martin的文章似乎並沒有參考soa（也許參考得不夠，也許根本就忽略了）。最近，在與steve進行了交流後，針對這一話題，文章新增了乙個側邊欄（sidebar）。不過，steve認為這不僅是遠遠不夠的，反而與事實毫不相干：\
[...]這並不是soa的真正定義，而只是介紹了陳舊的「龐大的」esb以及ws-*術語，rest擁護者（restafarians）在闡述他們的方式為何更好時慣用這樣的手法。按照這篇文章的說法，它「清楚（crisply）」地描述了微服務的風格，因此在與soa的對比方面也是有根據的，他們將soa描述為「soa意味著太多的事情」。這一點上，我完全不能同意，首先如果能夠闡述清楚如何適應非微服務的方式，那微服務可能更多的是一種實現，這一點上soa已經做得很好了，其次，它沒有解釋什麼能夠使服務變得「微小（micro）」，服務可能是由規模恰當的團隊（12個人）制定的，也可能是單個人制定的。\
最後，steve重複了他的觀點，那就是微服務並不是什麼新鮮的理念，僅僅是一種面向服務交付（service oriented delivery）的方式。在他看來架構師和開發人員最好使用soa，因為它的定義更加完備並且現在已經取得了更多的經驗。與其將微服務定義為什麼新事物，還不如談論一下「如今」的soa。steve這樣說到：\
另外，在文章的腳注中重點提及了netflix，實際上它所使用的詞彙是「細粒度的soa」，另外乙個案例（amazon）\討論的也是soa。
那麼您的觀點是什麼呢？微服務僅僅是soa呢，還是提供了一些根本上有所區別的東西呢？\
檢視英文原文：microservices and soa
\\ 感謝張龍對本文的審校。
\
SOA 與 微服務的區別
什麼是soa soa service oriented architecture 面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分布式部署 組合和使用。服務層是soa的基礎，可以直接被應用呼叫，從而有效控制系統中與軟體 互動的人為依賴性。soa是一種粗粒度 松耦合服務架構，服務之...
SOA 與 微服務的區別
什麼是soa soa service oriented architecture 面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用元件進行分布式部署 組合和使用。服務層是soa的基礎，可以直接被應用呼叫，從而有效控制系統中與軟體 互動的人為依賴性。soa是一種粗粒度 松耦合服務架構，服務之...
微服務理論之四 SOA
soa代表了面向服務的架構。soa是一種使用松耦合的黑盒子服務構建業務應用的體系架構，這些服務可以通過編排連線在一起以實現特定的功能。以下是服務的soa的主要特點 a soa元件是松耦合的。當我們說鬆耦合，這意味著每乙個服務是自包含單獨存在的邏輯。舉例來說，我們採取了 支付閘道器 的服務，並將它附加...