1樓：kimmking
實際上服務劃分的本質是對系統進行架構設計，服務的劃分粒度沒有絕對的過大或過小之說，不同階段的側重點和思考的角度也不盡相同。創業初期的團隊，過分的追求微服務，為了「微」而微，反而會導致業務邏輯過於分散，技術架構過於複雜，團隊基礎設施搭建能力弱，進而導致忽略了快速迭代交付產品的重要性，可能錯失了市場機會。所以，關於服務的劃分不是對錯的選擇題，而是需要綜合考慮各種外界的因素，所作出的乙個最適合的決策，這些外界因素通常包括業務、技術債、開發、運維、測試這五個方面：
業務所處領域的市場性質
對市場比較敏感的專案，創業初期粒度應該盡量劃分的粗一些，先提供充足的彈藥去占領市場，然後再去考慮對系統進行重構和優化；
與原有系統之間的關係
對於歷史遺留的系統，需要做好新舊系統之間的邊界劃分，避免過於激進、過大幅度的改造，應該採取小步快跑的方式，有節奏的對老系統進行服務化改造；
開發團隊的成熟度
服務化帶來的技術風險應該提前進行評估，要考慮團隊的承受度，用合適的人做適合的事；
基礎設施的搭建能力
在進行細粒度的服務劃分時，要考慮團隊是否有足夠的能力來支撐大量服務例項執行的運維複雜度，是否可以做好分布式的日誌追蹤和服務的監控；
測試團隊的測試執行效率
過於細粒度的服務劃分，如果測試團隊不能通過自動化測試、自動回歸、壓力測試、極限測試等手段來提高測試執行效率，必然會帶來測試工作量的大幅度上公升，進而影響整個專案的上線週期；
進行服務化的拆分時，通常會先按照業務子系統先進行一次劃分，根據業務邏輯和資料的關係劃分為若干個子系統，然後再考慮子系統內部是否可以再次進行拆分。
2樓：「已登出」
目前看和你做的那塊事情有關聯。
一般我們會從業務上面分領域拆分服務，但是同一領域也可能拆分不同服務，比如有些公共模組資料很多模組（比如訂單）需要引用，那我拆乙個持久層出來給到其他服務，上層再放乙個邏輯服務；也有些服務呼叫量巨大，那我把一些介面按呼叫量/快慢做分離，方便其中部分介面快速擴容；有些模組業務邏輯複雜，需要多個開發在裡面，那麼我再拆拆更小模組，讓不同開發專注於某些模組。總的來說服務拆分最開始和我們之前拆模組沒有太大區別，後面也可能為了分離快慢介面，呼叫量多少介面做一些拆分。但大多數還是按照之前如何拆模組來搞
3樓：
我有個思路，聽聽就好：你可以先一分二，再分四，四分八，這樣慢慢摸索。不要一步邁的太大，一次劃分的太多。
我看了一些微服務的書籍和部落格，所有的這些文章其實都是講理論或者給某某框架打廣告，所以對你們來說就沒什麼實際的意義。
再說整個系統向微服務架構的轉變是需要架構師來經過慎重考慮，和po, pm, stakeholder協調扯皮無數次後才能達到的妥協方案罷了。這個我不是瞧不起普通程式設計師，只是在微服務付諸實踐之前，得全盤考慮，說白了，在我有限的公司工作經歷（乙個破產，乙個剛成立）中，影響產品的，技術上的因素其實最不重要，你手上有多少人頭，有多少資源，如何排期，和stakeholder討價還價，如何兜售你的技術以及帶來的好處，講乙個好的故事，或許能更影響技術的決定。
4樓：Keegan小鋼
需要考慮的因素主要有：專案大小、專案所處的階段、團隊人員、時間上的要求等。要知道，微服務的服務數量越多系統就越複雜，如果團隊能力不足，那齣問題的可能性就更大。
所以，一般在專案初期，人員也不多，服務粒度一般會設定得大一點，甚至不用微服務。乙個微服務系統正常的演化過程也是從大粒度的服務開始，慢慢拆分成更多小粒度的服務的。
伺服器架構設計的重難點有哪些？
逐風 無聊刷題玩，隨便答答。1.介面和協議的通用性。2.分布式的便捷度。3.實現友好度。4.負載能力 5.容錯能力 6.可追溯能力 7.未來的擴充套件性 李傳學 談重難點首先要看伺服器架構設計的目標是什麼？目標應該是高吞吐力以及異常壓力下的穩定輸出。要達到這個目標又要看你的服務特定是什麼，根據特點擊...
如何評價《守望先鋒》架構設計？
a阿拉 哈哈 這個跟前端開發中的redux 叫好不叫座如出一轍啊，看來深刻體會了每種架構設計都有其自身設計的適用場景和運用範圍，比如redux 適用於時間旅行 記錄 回放，集中式資料來源的場景，比如編輯器 很抱歉，實在沒做過其他更適合的場景 ECS 適合有延遲的公網多人聯機網遊，跟傳統開發模式比起來...
微服務架構中可以直接使用資料庫作為註冊中心嗎？
小小笑兒 可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心 類似 eureka 三觀成型沒法改 可以其實大多數公司連日均8000pv的訪問坎都過不去，my...