上篇簡單介紹了微服務(wù)啸箫，列舉了單塊應(yīng)用和微服務(wù)的一些區(qū)別，之后又在網(wǎng)上閱讀了別人寫的一些微服務(wù)文章伞芹，對比之下感覺自己的歸納和文筆還是差的太遠(yuǎn)忘苛，以后還需多練。
既然要使用微服務(wù)唱较，那就必須要考慮如何對整個(gè)系統(tǒng)進(jìn)行分解扎唾，哪些功能應(yīng)該放到一個(gè)服務(wù)中，哪些不應(yīng)該南缓，即確定微服務(wù)的邊界胸遇。有人會覺得這個(gè)問題很頭疼，無從下手汉形，也有人會覺得這個(gè)很簡單纸镊，但是分解后的服務(wù)不斷出現(xiàn)各種問題，讓后續(xù)的開發(fā)變得十分痛苦概疆。
我認(rèn)為找到邊界是采用微服務(wù)架構(gòu)的最基本前提逗威，也是最有挑戰(zhàn)的部分，在沒有認(rèn)清服務(wù)邊界的情況下岔冀，不要輕易使用微服務(wù)凯旭，否則可能帶來很多意想不到的問題和麻煩。
什么樣的微服務(wù)邊界是合適的使套？
了解面向?qū)ο笤O(shè)計(jì)的朋友應(yīng)該對“單一職責(zé)原則”罐呼、“開閉原則”等基本原則都不陌生，這些原則在架構(gòu)方面同樣十分受用侦高。架構(gòu)的核心價(jià)值不在于使用多么先進(jìn)或者NB的技術(shù)嫉柴，而在于使系統(tǒng)具有高度可擴(kuò)展性，從而靈活應(yīng)對業(yè)務(wù)的不斷變化奉呛，持續(xù)演進(jìn)差凹。有句話說的好，“架構(gòu)不是設(shè)計(jì)出來的侧馅，而是演進(jìn)出來的”危尿。而擴(kuò)展性的基礎(chǔ)就是松耦合、高內(nèi)聚馁痴，這是我們應(yīng)該多花一些心思思考的地方谊娇。
松耦合
微服務(wù)之間應(yīng)該是高度松耦合的，從而避免一個(gè)微服務(wù)中的問題擴(kuò)散到整個(gè)系統(tǒng)。如何判斷是不是松耦合济欢，最直接的一點(diǎn)就是可以獨(dú)立修改和部署一個(gè)服務(wù)而不影響系統(tǒng)其他部分赠堵，如果修改一個(gè)功能時(shí)不得不對系統(tǒng)其他部分也同時(shí)做出修改，那么就要反思服務(wù)的邊界是不是有問題了法褥。
松耦合的服務(wù)應(yīng)盡可能避免暴露內(nèi)部實(shí)現(xiàn)細(xì)節(jié)茫叭，因?yàn)楸┞秲?nèi)部實(shí)現(xiàn)細(xì)節(jié)意味著服務(wù)的修改，可能會需要服務(wù)的消費(fèi)方也要跟著修改半等。此外也應(yīng)該避免存在多種服務(wù)間的調(diào)用方式揍愁，這樣也會增加服務(wù)的耦合度。
高內(nèi)聚
既然要避免修改一個(gè)服務(wù)的時(shí)候帶來系統(tǒng)其它部分的修改杀饵，就要保證相關(guān)行為都放在一個(gè)服務(wù)內(nèi)莽囤，這就是高內(nèi)聚的核心，也即我們思考如何找到服務(wù)邊界要考慮的核心問題切距。
前篇有說過朽缎，“一個(gè)微服務(wù)只專注于一種業(yè)務(wù)，遵循單一職責(zé)原則”谜悟，即微服務(wù)的專注话肖，要確保專注，就不能有其他無關(guān)行為夾雜進(jìn)來葡幸，也不能有自身相關(guān)行為偷溜到其他系統(tǒng)中狼牺，要準(zhǔn)確的把握所有相關(guān)行為并牢牢地把它們拴在一起。
什么方法能找到微服務(wù)邊界礼患？
分層
很多應(yīng)用都會采用分層架構(gòu)是钥，所以會有種劃分微服務(wù)方案，就是直接將原來的分層作為系統(tǒng)分解的邊界缅叠，分解出來的微服務(wù)各自負(fù)責(zé)一個(gè)層的工作悄泥。比如一個(gè)可能很多人見過的例子，就是把數(shù)據(jù)持久化層單獨(dú)做成一個(gè)服務(wù)肤粱，它負(fù)責(zé)所有的數(shù)據(jù)庫操作弹囚，帶來的好處是業(yè)務(wù)開發(fā)只需關(guān)注業(yè)務(wù)模型，而不用考慮底層存儲领曼，有專門的團(tuán)隊(duì)對持久化服務(wù)進(jìn)行迭代和優(yōu)化鸥鹉，對業(yè)務(wù)模型和數(shù)據(jù)存儲做適配，但是隨之而來的問題是大部分業(yè)務(wù)的修改都需要該服務(wù)同時(shí)也跟著修改庶骄，新的業(yè)務(wù)需求需要業(yè)務(wù)開發(fā)團(tuán)隊(duì)和持久化服務(wù)開發(fā)團(tuán)隊(duì)進(jìn)行大量溝通才能進(jìn)行毁渗，服務(wù)針對某個(gè)業(yè)務(wù)作出修改后導(dǎo)致其他業(yè)務(wù)出現(xiàn)問題等等，所以系統(tǒng)雖然做了分解单刁，但仍然是高耦合的灸异，無法獨(dú)立對一個(gè)服務(wù)隨時(shí)進(jìn)行修改和部署。
分割
如果說水平的分層作為服務(wù)邊界不是一個(gè)好的選擇，那么垂直分割又如何肺樟？通常一個(gè)良好的系統(tǒng)在開發(fā)時(shí)都會考慮用模塊來組織代碼檐春，將不同的行為放在不同的模塊中，比如訂單模塊么伯、支付模塊疟暖，如果設(shè)計(jì)得當(dāng)，各個(gè)模塊之間的耦合會相對較低田柔，業(yè)務(wù)邏輯基本都是高內(nèi)聚的俐巴，只是共用了一些非業(yè)務(wù)邏輯的代碼，所以按照模塊的邊界來分割系統(tǒng)應(yīng)該是不錯(cuò)的切入點(diǎn)凯楔。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）
在QCon倫敦2016大會上，《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書的作者Eric Evans提出锦募，使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）概念減少微服務(wù)環(huán)境中通用語言的復(fù)雜性摆屯。Evans建議，將每個(gè)微服務(wù)設(shè)計(jì)成一個(gè)DDD限界上下文糠亩，這為系統(tǒng)內(nèi)的微服務(wù)提供了一個(gè)邏輯邊界虐骑，無論是功能，還是通用語言赎线。
限界上下文（Bounded Context）為高內(nèi)聚提供了很好的理論指導(dǎo)廷没，它的核心就是將特定職責(zé)的相關(guān)行為控制在一個(gè)有顯示邊界的范圍內(nèi)，Evans的一個(gè)比喻非常形象：“細(xì)胞之所以會存在垂寥，是因?yàn)榧?xì)胞膜定義了什么在細(xì)胞內(nèi)颠黎，什么在細(xì)胞外，并且確定了什么物質(zhì)可以通過細(xì)胞膜”滞项。近年來微服務(wù)的興起又為DDD提供了很好的應(yīng)用場景狭归，只要深入挖掘領(lǐng)域知識，識別出合理的上下文文判，就能合理拆分微服務(wù)过椎。
不過我覺得領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是一門需要長時(shí)間積累的學(xué)問，你需要和領(lǐng)域?qū)＜页浞譁贤ㄏ凡郑餐页鐾ㄓ谜Z言疚宇，逐步深入挖掘領(lǐng)域知識來對領(lǐng)域模型進(jìn)行迭代，這是一個(gè)持續(xù)的過程赏殃，因此在初期對領(lǐng)域知識掌握有限的情況下敷待，不應(yīng)急著過早劃分細(xì)粒度的上下文。比較好的方式是先找出粗粒度的上下文仁热，循序漸進(jìn)讼撒，隨著領(lǐng)域知識的深入再逐步分解，這個(gè)過程可能是長期的，頗具挑戰(zhàn)的根盒，而且往往會走一些彎路钳幅、遠(yuǎn)路，但是隨著領(lǐng)域知識的沉淀和經(jīng)驗(yàn)的積累炎滞，最終總是能得出更加準(zhǔn)確的上下文邊界和模型的敢艰。
總結(jié)
微服務(wù)要求有低耦合、高內(nèi)聚的邊界册赛，使用 DDD 的限界上下文作為微服務(wù)邊界是一種很合理的方式钠导，但是服務(wù)的拆分應(yīng)隨著領(lǐng)域知識的深入逐步迭代進(jìn)行，不可操之過急森瘪。所以重點(diǎn)又落在了 DDD 上牡属，這也是我一直以來最感興趣的架構(gòu)思想，待以后對 DDD 的精髓有了更深的理解再和大家進(jìn)一步分享和交流扼睬。
