認識微服務
以及他們周邊的一些小知識
微服務建立
我們一直在尋找更好的系統建構方式，隨著許多前輩們的實現應用趨勢，讓我有服務慢慢火熱起來，現在許多人使用微服務架構來快速交付軟體，並擁抱新技術，增加軟體開發的自由度。
什麼是微服務？
微服務是一種分散式系統的做法，主要是根據業務領域來建構。
微服務根據定義：是一群協同運作的小型自主服務。因為我們不斷地寫新的程式碼，程式越來越大，讓維護變得很困難，所以微服務採取把程式邏輯抽象化或模組化，讓程式可以符合單一原則，只需要專注在他要提供的服務即可。
微服務強調自主性
微服務是獨立的實體，透過網路呼叫來溝通，使得服務之間可以分割邏輯，避免緊密聚合造成難以維護，因為太多共用的話，當問題出現的時候，會分不清楚哪個東西造成問題。
微服務架構允許不同的團隊分別專注於不同的服務。這種分工可以提高效率，因為每個團隊可以獨立工作，不必等待其他團隊完成。此外，團隊可以根據其專長選擇最適合的技術架構，這增加了靈活性並促進創新。
主要的好處
通常我們在講微服務會有以下的好處：技術的異質性，因為我們程式邏輯間的溝通是透過API來互相傳送資料，所以可以用不同語言的邏輯來傳送資料。
高度的容錯力，因為我們把邏輯間做分割，所以一旦某一個元件失敗的時候，這個失敗不會影響到其他的邏輯。
接著是部署，我們可以針對單一的服務做變更並且部署到雲端或者是機器上，而不是要一口氣完成所有的東西才可以進行部署，在這樣的情況下我們可以快速更新某一個功能。同時這邊我們可以發現到程式的擴展性也是很彈性的，原因是我們可以隨時針對單一功能進行擴展，讓程式可以應付市場變化。
最後一個是可替換性，因為我們的服務單一化，所以只要針對出問題的那一段或者是已不再使用的技術，進行替換或移除程式對應變化，不需要改變整體即可達到目的。
微服務的缺點
首先是程式語言有可能一直改變，原因如前面所述，我們可以用不同的語言進行不同邏輯的運作，所以可能需要很多人力來處理不同的語言維護，在我所知且我所經歷過的開發過程中，程式庫通常會用相同的語言撰寫，或者在相同的平台或作業系統上運行。
因為微服務系統勢必導致較多的模組，所以維護上可能非常的困難，因為各個模組間的串聯不是非常容易。且微服務並非萬能的銀彈，根據前面的優點，你會知道在微服務方面你必須處理部署測試與監控的問題，怎麼樣 Trace 到底哪邊發生錯誤，有這樣的基本技術能力，才能換取到使用微服務的優勢。所以微服務並非一個最佳解法，而是要根據情況來決定是否使用此架構。
容器技術與微服務
容器技術，如 Docker 和 Kubernetes，與微服務架構密切相關。容器為微服務提供了一個輕量級、一致的運行環境，使得部署、擴展和管理變得更加容易。這些技術的結合已成為現代軟體開發中的一個重要趨勢。
架構師在做什麼？
想像一下，你正在規劃建築物，你會怎麼分配房間？是三房兩廳完全沒有廁所，還是你會分配一個客廳一間廁所？架構師必須考量當前的建築是否符合居住需求，並且考慮將來使用上會不會有問題，該如何分配房間邊界，可能中間還要搭配風水、藝術配置、視覺等等等。總之就是追求最佳化的配置。
回到軟體架構上，軟體架構師在想什麼？他在想不同服務之間發生什麼事，而放任服務裡頭發生什麼事。架構師可能要像架構出來了軟體是否符合市場需求，是否符合實務的做法，例如這個做法可以符合資安標準，或者可以用 RESTful 標準進行資料交換。
微服務與架構師
軟體架構師不僅要考慮技術決策，還要管理與這些決策相關的風險。例如，選擇微服務架構可能會帶來某些性能和複雜性的挑戰。架構師需要平衡這些風險與架構帶來的好處。
在決定使用微服務架構時，軟體架構師必須確保技術選擇與組織的業務目標和策略一致。這意味著架構不僅要在技術上可行，還要能夠支持組織的整體目標，如針對市場的需求能快速反應、同時在有效的成本下建立出服務，以及創新的能力。
除了處理當前的技術挑戰，架構師還需要從長遠的角度規劃。這包括預測未來的技術趨勢、擴展性需求和市場變化。架構師必須思考這些面向來確保系統的可持續發展性。
結論
微服務架構是現代軟體開發的一個趨勢。然而，正如任何架構的選擇有好有壞，這樣的微服務概念也帶來了要克服的挑戰和價值衡量。軟體架構師在這個過程中扮演著關鍵角色，他們的決策將影響產品的品質以及交付速度。
