• 什么樣的服務(wù)是好服務(wù)

　　松耦合：能夠獨(dú)立修改及部署單個(gè)服務(wù)而不需要修改系統(tǒng)的其它部分。

　　高內(nèi)聚：把相關(guān)的行為聚集在一起，把不相關(guān)的行為放在別處。這樣如果要改變某個(gè)行為時(shí)，就能夠只在一個(gè)地方進(jìn)行修改，然后就可以盡快發(fā)布了。

?

• 界限上下文

　　任何一個(gè)給定的領(lǐng)域都包含多個(gè)界限上下文，每個(gè)界限上下文中的東西分成兩部分，一部分不需要與外部通信，另一部分則需要。每個(gè)上下文都有明確的接口，該接口決定了它會暴露哪些模型給其他的上下文。

?

• 留心過多的約定

　　有些工具會為了短期利益而犧牲長期利益，為了讓你一開始啟動得足夠快，它們會使用一些不好的實(shí)踐。比如有些框架可以很容易地表示數(shù)據(jù)庫對象，并把它們反序列化成進(jìn)城內(nèi)的對象，然后直接暴露給外部。這種方式內(nèi)在的耦合性所帶來的痛苦會遠(yuǎn)遠(yuǎn)大于一開始就消除概念之間的耦合所需要的代價(jià)。

　　我們很容易把存儲的數(shù)據(jù)直接暴露給消費(fèi)者，那么如何避免這個(gè)問題呢？一個(gè)很有效的模式是先設(shè)計(jì)外部接口，等到外部接口穩(wěn)定知道再實(shí)現(xiàn)微服務(wù)內(nèi)部的數(shù)據(jù)持久化。在此期間，簡單地將實(shí)體持久化道本地磁盤的文件上，當(dāng)然這并非長久之計(jì)。這樣做可以保證服務(wù)的接口是由消費(fèi)者的需求驅(qū)動出來的，從而避免數(shù)據(jù)存儲方式對外部接口的影響。其缺點(diǎn)是推遲了數(shù)據(jù)存儲部分的集成。

• 基于HTTP的REST的缺點(diǎn)

　　從易用性來講，基于HTTP的REST無法生成客戶端的樁代碼，而RPC可以。

　　有些Web框架無法很好地支持所有的HTTP動詞。

　　性能上也可能會遇到問題，基于HTTP的REST支持不同的格式，如JSON或二進(jìn)制，所有負(fù)載相對SOAP來說更加緊湊，在要求低延遲的場景下，每個(gè)HTTP請求的封裝開銷可能是個(gè)問題。所以，對于服務(wù)和服務(wù)之間的通信來說，如果低延遲或者較小的消息尺寸對你來說很重要的話，那么一般來講HTTP不是一個(gè)好方法。

　　有些RPC的實(shí)現(xiàn)支持高級的序列化和反序列化機(jī)制，然而對于REST而言，這部分工作就要自己做了。

?

轉(zhuǎn)載于:https://www.cnblogs.com/IvySue/p/6961441.html

總結(jié)

以上是生活随笔為你收集整理的《微服务设计》（三）---- 集成的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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