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