# 微服務一樣下半部 不然太短了 壞處以及建立的重點 那微服務架構有沒有不方便的地方呢 這邊列出要注意的細節: ### 1.產品的類型: 就如前面講到的 如果你們公司的專案 不是列出的那幾項 可能只是一般的形象網站 或是有期限的活動網站之類的 使用一條龍的方式就好了 畢竟為服務的架構會使原本的專案變得很龐大 ### 2.切割服務的挑戰： 不管是從0開始規劃微服務，或是從原本的單體式系統切割成適當的微服務都是一個挑戰，過度細分或過度集中都可能導致問題。 怎麼說 如果會員微服務裡面 發現含有商品的功能在裡面 是不是就不太對了 又或是會員的功能 你拆成了 青銅會員微服務 白銀會員微服務 黃金會員微服物 那這就多了唷 ### 3.單支微服務掛掉，不能影響到其他支微服務運作 比如說商品下面都會有個商品評語 這邊我們會拆成評語微服務 如果今天評語微服務有出現系統錯誤 我們會把評語為服務功能給關掉 而且在網頁上 應該是要看到評語區可能是掛上維護的圖案或文字之累的 提醒會員目前先不能用 且不應該會影響到商品為服務 商品一樣可以繼續下訂單 因為訂單微服務也是正常的 沒異常的微服務繼續可以讓使用者操作 這才是微服務的理念 我們關掉有問題的微服務 這個舉動可以叫做 服務降級 先知道就好 ### 4.a服務與b服務的 資料傳遞橋梁 一個會員進行訂單時，可能會涉及會員服務、訂單服務和支付服務的多個步驟。你需要確保這些步驟能夠順利協同工作。使用適當的通信機制，例如 API 調用或消息佇列，確保服務之間的順序和協同操作 以我知道的業界來說 通常會用以下的方式 RESTful API RabbitMQ Kafka GRPC 這幾個作為各微服務之間的資料傳遞方式 要熟知這些傳遞方式的用法和觀念 之後會介紹這三種資料傳遞方式的解說 想知道各位使用ms還有使用哪些傳遞方式 ### 5.你負責的微服務更新資料傳遞格式，有耐心地做協調 微服務的獨立運作意味著不同團隊可能負責不同的服務。 當更新一個微服務的資料傳遞格式時，需要有耐心並不斷與其他團隊協調與溝通。 你負責的會員微服務有個搜尋會員基本資料的接口 這個接口可能給報表服務 或是留言服務使用 而這接口的有一個參數要帶 就是會員帳號 用會員帳號茶資本資料 而這個參數的資料型態是iNT 要帶數字給這個接口 好 今天這個搜尋會員接口 參數 會員帳號 改成了STRING 變成要帶字串 如果負責會員微服務的團隊沒有跟 報表微服務和留言微服務團隊說 這兩個團隊還是帶數字過去 上到正式站 就爆了 所以說需要耐心解釋新的資料傳遞格式，以確保整個系統的一致性。 --- 還有很多更細節要注意的地方 但是新肝工程師只要先知道這些基本的即可 --- 最後重點 微服務並沒有說比單體式系統來的好 這兩個是完全不同的選擇 最終要取決於你們的產品走向 之後會有工作上的實務篇會講 資料庫有沒有必要也跟著微服務拆分 原本的微服務，是否功能過於龐大，如何在細拆得更精簡 下一篇會說 我當兵時候的鬼故事 那時候我在新竹542旅砲兵營 我們 下次見 -- * 儘管微服務架構具有許多優點，但也存在一些挑戰和壞處，這包括： 複雜性和管理難度： 微服務架構將系統分為多個小型服務，帶來了更複雜的基礎設施和管理。需要有效地協調和監控多個微服務，以確保它們協同運作。 //分布式系統的挑戰： 微服務通常運行在分布式環境中，這帶來了分布式系統的挑戰，例如處理分布式事務、一致性、通信延遲等問題。 //進階-開發者需求： 微服務可能需要團隊有更多的分散式系統知識和技能，這可能需要額外的培訓和投資。 部署和運維成本： 微服務的部署和運維可能比單體式應用更複雜，需要更多的自動化和管理工具，這可能增加相應的成本。 //進階-服務間通信成本： 由於微服務間需要進行通信，因此可能存在額外的通信成本。這包括網絡開銷、序列化/反序列化開銷等。 //進階-一致性和事務管理： 在微服務環境中實現一致性和事務管理可能更加複雜，需要仔細設計以避免一些分佈式系統常見的問題。 切割服務的挑戰： 決定如何將系統切割成適當的微服務是一個挑戰，過度細分或過度集成都可能導致問題。 //進階-安全性挑戰： 在分布式環境中實現安全性可能更為複雜，需要確保每個服務都得到適當的保護，同時處理跨服務的授權和身份驗證。 總的來說，微服務架構是一種強大的架構風格，但在採用之前，組織應評估其需求、團隊技能和預算，以確保它是合適的解決方案。* ---