1樓：倚天碼農
你講了了兩個問題。乙個是高度耦合（程式架構和設計），另乙個是http的呼叫效率。這兩個問題的解決方案一般情況下是互相矛盾的。
要想解決高度耦合，就需要優雅的設計，但一般效率都不高。要想提高效率，就要使用一些特殊的設計和手段，這必然使程式設計很難看。
我們先來看高度耦合（程式架構和設計），模組拆分之後的關鍵是他們之間如何互相呼叫。有兩種方法，一種是RPC，另一種是事件驅動。事件驅動可以解決耦合的問題，但它有資料一致性的問題。
RPC沒有資料一致性的問題，但是緊耦合的。現在公認的比較好的微服務之間的呼叫方式是事件驅動，但如果你的業務本身是緊耦合的，那麼我不覺得RPC有什麼問題。請參閱「微服務之間呼叫的最佳設計」和「微服務的資料庫設計」。
這裡面詳細比較了不同呼叫方式之間的差異。
關於http的呼叫效率，在微服務中乙個請求需要呼叫很多服務才能完成，這個是比較普遍的。多數情況下是能滿足需求的。可以有一些其他辦法來解決，例如快取或並行呼叫多個微服務。
如果最後認定是http的問題那麼有兩個關鍵，乙個是協議本身的效率，另乙個是序列化的效率。你也許需要選擇更高效率的協議，例如gRPC+Protobuf就是更高效的協議，不過你的程式可能改動比較大。
2樓：Harry Huang
先全部整合到一起，等待產品上線後根據資料量再考慮如何進行微服務化。
另外，所有服務都在乙個包裡，接上zuul多跑幾個相同的全功能服務你認為會有什麼問題？
不要為了微服務而微服務。
3樓：
目前公司業務也開始準備著手做重構，我發現目前存在的乙個問題就是不同微服務之間些常用類或者工具類，每個微服務都需要單獨重寫
4樓：
我覺得架構上並沒有太大的問題。
http互相呼叫效率很低可以加快取啊。
比如使用者搜尋了商品，把搜尋的key和商品快取起來。在訂單模組拿商品資訊的時候先從快取裡取。使用者資訊也是同理，放快取。
優惠券可能需要實時去調，感覺問題也不大啊。
開發人員可以按組來分，比如你說的訂單、使用者、商品、支付四個模組就分成4個組。
介面文件維護好，就可以了。
5樓：付大力
效率很低：比起程序內通訊，http呼叫確實會有一定效能的損耗，但是你確定這個損耗確定影響到你的業務需求和使用者體驗了？如果確實影響到了，如果基於http協議進行通訊的微服務框架可能都不太適合你。
拆分過後服務可以根據瓶頸擴容，我覺得後期量上去了之後，同等資源的情況下因為可以根據瓶頸擴容會抵消掉一些效能的損耗。
資料一致性：在進行模組拆分的時候，我們應該盡可能把資料耦合緊的或者需要進行事務處理的資料放在乙個模組，如果不同模組之間事務型的處理較多，我們應該重新思考我們的模組拆分是否合理。
人員：可以按模組進行人員的劃分，如果你們現在還沒有這樣子做，推薦你們這樣子做。這樣子可以讓各模組的工作人員更加專注，同時也有利於他們深入的優化重構。
如果你們團隊是人數比較少不能進行這樣子的拆分，那只能說明可能對於你們現階段的規模可能不太適合採用微服務
Spring Cloud架構的各個元件的原理分析
已登出 當時準備考北林於是看到了這個知乎，現在考入北林了覺得評價的不真實啊。七人間，桌子衣櫃我覺得都夠啊。暖氣空調也很給力每層樓的公共廁所真的很乾淨，每天都有人早中晚打掃。北方宿舍普遍較差。北林算是北京比較好的了，對比了高中同學現在的情況。的確如此。 他的大王 更新一下吧 即將讀研究生，暑假住臨時宿...
Instagram 接入電商並進行電商變現的潛力大麼？
已登出 電商這個詞聽得多但是具體的含義好多人並不理解，但是有一點 只要涉及到錢，那就有對立的一面就是納稅，什麼都可以存在，包括電商，但前提如果沒有納稅那就是違法，而違法行為是長遠不了的。 Kut Pro 樓上幾個回答還算符合現況 且除了上述原因之外，從使用者資料更可以映證IG對於電商變現能力的表現1...
跨境電商？
愛店家天貓商城入駐 跨境電商自主創業同別的做生意自主創業沒什麼很大的差別，只不過便是自身去資金投入隨後產出率，自主創業是大部分人如今的挑選，由於工作時間不但不自由，工資也就那一些，想認真工作完成漲薪?不會有的，好看得話誰都是說，因此在被坑了一次次的大家，都是挑選踏入自主創業這條路面，即使被自身坑也不...