1.SOA架構(gòu)和微服務(wù)架構(gòu)的區(qū)別
首先SOA和微服務(wù)架構(gòu)一個(gè)層面的東西，而對于ESB和微服務(wù)網(wǎng)關(guān)是一個(gè)層面的東西抽活，一個(gè)談到是架構(gòu)風(fēng)格和方法覆获，一個(gè)談的是實(shí)現(xiàn)工具或組件。
1.SOA（Service Oriented Architecture）“面向服務(wù)的架構(gòu)”:他是一種設(shè)計(jì)方法崩泡，其中包含多個(gè)服務(wù)， 服務(wù)之間通過相互依賴最終提供一系列的功能猬膨。一個(gè)服務(wù) 通常以獨(dú)立的形式存在與操作系統(tǒng)進(jìn)程中角撞。各個(gè)服務(wù)之間 通過網(wǎng)絡(luò)調(diào)用。
2.微服務(wù)架構(gòu):其實(shí)和 SOA 架構(gòu)類似,微服務(wù)是在 SOA 上做的升華勃痴，微服務(wù)架構(gòu)強(qiáng)調(diào)的一個(gè)重點(diǎn)是“業(yè)務(wù)需要徹底的組件化和服務(wù)化”谒所，原有的單個(gè)業(yè)務(wù)系統(tǒng)會拆分為多個(gè)可以獨(dú)立開發(fā)、設(shè)計(jì)沛申、運(yùn)行的小應(yīng)用劣领。這些小應(yīng)用之間通過服務(wù)完成交互和集成。
微服務(wù)架構(gòu) = 80%的SOA服務(wù)架構(gòu)思想 + 100%的組件化架構(gòu)思想 + 80%的領(lǐng)域建模思想
2.ESB和微服務(wù)API網(wǎng)關(guān)铁材。
1.ESB（企業(yè)服務(wù)總線）尖淘，簡單 來說 ESB 就是一根管道，用來連接各個(gè)服務(wù)節(jié)點(diǎn)著觉。為了集 成不同系統(tǒng)德澈，不同協(xié)議的服務(wù)，ESB 做了消息的轉(zhuǎn)化解釋和路由工作固惯，讓不同的服務(wù)互聯(lián)互通梆造；
2.API網(wǎng)關(guān):API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)的唯一入口葬毫。從面向?qū)ο笤O(shè)計(jì)的角度看镇辉，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)贴捡，為每個(gè)客戶端提供一個(gè)定制的API忽肛。它可能還具有其它職責(zé)沿盅，如身份驗(yàn)證诽里、監(jiān)控、負(fù)載均衡拗馒、緩存、請求分片與管理罕模、靜態(tài)響應(yīng)處理评腺。API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)淑掌，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能蒿讥。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API抛腕。服務(wù)端通過API-GW注冊和管理服務(wù)芋绸。
3.SOA架構(gòu)特點(diǎn)：
系統(tǒng)集成：站在系統(tǒng)的角度，解決企業(yè)系統(tǒng)間的通信問 題担敌，把原先散亂摔敛、無規(guī)劃的系統(tǒng)間的網(wǎng)狀結(jié)構(gòu)，梳理成 規(guī)整全封、可治理的系統(tǒng)間星形結(jié)構(gòu)舷夺，這一步往往需要引入 一些產(chǎn)品，比如 ESB售貌、以及技術(shù)規(guī)范、服務(wù)管理規(guī)范疫萤； 這一步解決的核心問題是【有序】
系統(tǒng)的服務(wù)化：站在功能的角度颂跨，把業(yè)務(wù)邏輯抽象成 可復(fù)用、可組裝的服務(wù)扯饶，通過服務(wù)的編排實(shí)現(xiàn)業(yè)務(wù)的 快速再生恒削，目的：把原先固有的業(yè)務(wù)功能轉(zhuǎn)變?yōu)橥ㄓ?的業(yè)務(wù)服務(wù)，實(shí)現(xiàn)業(yè)務(wù)邏輯的快速復(fù)用尾序；這一步解決 的核心問題是【復(fù)用】
業(yè)務(wù)的服務(wù)化：站在企業(yè)的角度钓丰，把企業(yè)職能抽象成 可復(fù)用、可組裝的服務(wù)每币；把原先職能化的企業(yè)架構(gòu)轉(zhuǎn)變?yōu)榉?wù)化的企業(yè)架構(gòu)携丁，進(jìn)一步提升企業(yè)的對外服務(wù)能力；“前面兩步都是從技術(shù)層面來解決系統(tǒng)調(diào)用兰怠、系統(tǒng)功能復(fù)用的問題”梦鉴。第三步，則是以業(yè)務(wù)驅(qū)動把一個(gè)業(yè)務(wù)單元封裝成一項(xiàng)服務(wù)揭保。這一步解決的核心問題是【高效】
4.微服務(wù)架構(gòu)特點(diǎn)：
1.通過服務(wù)實(shí)現(xiàn)組件化
開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響肥橙。
2.按業(yè)務(wù)能力來劃分服務(wù)和開發(fā)團(tuán)隊(duì)
開發(fā)者可以自由選擇開發(fā)技術(shù)，提供 API 服務(wù)
3.去中心化
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫持久化業(yè)務(wù)數(shù)據(jù)
每個(gè)微服務(wù)只能訪問自己的數(shù)據(jù)庫秸侣，而不能訪問其它服務(wù)的數(shù)據(jù)庫
某些業(yè)務(wù)場景下存筏，需要在一個(gè)事務(wù)中更新多個(gè)數(shù)據(jù)庫宠互。這種情況也不能直接訪問其它微服務(wù)的數(shù)據(jù)庫，而是通過對于微服務(wù)進(jìn)行操作椭坚。
數(shù)據(jù)的去中心化予跌，進(jìn)一步降低了微服務(wù)之間的耦合度，不同服務(wù)可以采用不同的數(shù)據(jù)庫技術(shù)（SQL藕溅、NoSQL等）匕得。在復(fù)雜的業(yè)務(wù)場景下，如果包含多個(gè)微服務(wù)巾表，通常在客戶端或者中間層（網(wǎng)關(guān)）處理汁掠。
4.基礎(chǔ)設(shè)施自動化（devops、自動化部署）
的Java EE部署架構(gòu)集币，通過展現(xiàn)層打包WARs考阱，業(yè)務(wù)層劃分到JARs最后部署為EAR一個(gè)大包，而微服務(wù)則打開了這個(gè)黑盒子鞠苟，把應(yīng)用拆分成為一個(gè)一個(gè)的單個(gè)服務(wù)乞榨，應(yīng)用Docker技術(shù)，不依賴任何服務(wù)器和數(shù)據(jù)模型当娱，是一個(gè)全棧應(yīng)用吃既，可以通過自動化方式獨(dú)立部署，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中跨细，通過輕量的通訊機(jī)制聯(lián)系鹦倚，經(jīng)常是基于HTTP資源API，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建冀惭，能實(shí)現(xiàn)集中化管理（因?yàn)榉?wù)太多啦震叙，不集中管理就無法DevOps啦）。
5.主要區(qū)別：
6.Dubbo服務(wù)的最佳實(shí)踐
分包
服務(wù)接口散休、請求服務(wù)模型媒楼、異常信息都放在api里面，符合重用發(fā)布等價(jià)原則戚丸，共同重用原則
api里面放入spring 的引用配置划址。 也可以放在模塊的包目錄下。
粒度
盡可能把接口設(shè)置成粗粒度限府，每個(gè)服務(wù)方法代表一個(gè)獨(dú)立的功能猴鲫，而不是某個(gè)功能的步驟。否則就會涉及到分布式事務(wù)
服務(wù)接口建議以業(yè)務(wù)場景為單位劃分谣殊。并對相近業(yè)務(wù)做抽象拂共，防止接口暴增
不建議使用過于抽象的通用接口? T T<泛型>，接口沒有明確的語義姻几，帶來后期的維護(hù)
版本
每個(gè)接口都應(yīng)該定義版本宜狐，為后續(xù)的兼容性提供前瞻性的考慮 version （maven -snapshot）
建議使用兩位版本號势告，因?yàn)榈谌话姹咎柋硎镜募嫒菪陨墸挥胁患嫒輹r(shí)才需要變更服務(wù)版本
當(dāng)接口做到不兼容升級的時(shí)候抚恒，先升級一半或者一臺提供者為新版本咱台，再將消費(fèi)全部升級新版本，然后再將剩下的一半提供者升級新版本
預(yù)發(fā)布環(huán)境
推薦用法
在provider端盡可能配置consumer端的屬性
比如timeout俭驮、retires回溺、線程池大小、LoadBalance
配置管理員信息
application上面配置的owner 混萝、 owner建議配置2個(gè)人以上遗遵。因?yàn)閛wner都能夠在監(jiān)控中心看到
配置dubbo緩存文件
注冊中心的列表
服務(wù)提供者列表
