來來來！小笠宏樹 老師報名牌有沒有在聽！看這支，上禮拜老師講過的，看到沒有一直漲一直漲一直漲，你都不聽那老師有什麼辦法！

今天來分享個什麼呢～
The Offspring - The Kids Aren't Alright

好滴！看標題就知道要聊的是“微服務”，那至於為什麼是膽戰心驚呢？這是因為我本身只是個Android工程師，因此我沒有寫過後端，也沒有很熟微服務是什麼，所以我超怕講錯的ＸＤ。
那話又說回來為什麼身為Android工程師的我想硬是要聊微服務呢？這是因為前面的文章通常都是利用程式架構去了解公司的運作，頂多到兩者互相應證的程度，因此在這個系列我希望帶給各位讀者的是利用公司的運作邏輯去理解一個新的程式架構可能產生的優缺點。但還是很抖啦ＱＱ，如果有講錯還麻煩各位讀者留言討論～

微服務

網路的定義

微服務 (Microservices) 是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Language-Independent/Language agnostic) 的 API 集相互通訊。（from Wiki百科)

好，看到這裡，果然是個超出我理解範圍的東西。讓我來試著代換一下，恩～我看到了一些關鍵字像是“單一責任與功能”、“區塊”、“組合”等等，感覺可以用子公司或公司分拆這件事來代入，其實應該也有其他類似的例子，但因為這個還沒寫過就先用這個吧～

公司分拆

目的

邏輯越來越複雜

• 公司角度
  • 公司的體質部門之間的溝通邏輯越複雜，很容易一個簡單的合作要找到對應的資源要處理非常久，因此不如把幾個較為重要的流程拆開來互相配合，舉個例子：全家這間大公司將物流、系統、行銷等等的不同功能拆分成不同的子公司，這時候假如行銷需要客製化系統，那就去找負責做系統的公司。
• 微服務角度
  • 轉而對於要做成微服務的理解就是，假如全部都是在同一個架構中，那這個架構會非常的複雜，而在要如何找到所需的、正確的資料或方法也會比較困難，因此不如拆開來變成多個微服務，每個服務負責自己的，這樣架構上的耦合就會被強制分離，因此如果想要找到“使用者名稱”的資料時，只需要看看跟“使用者”這個服務有哪一個溝通手段可以知道使用者名稱就好。

定義規則麻煩

• 公司角度
  • 當公司越來越大，要定義公司文化或規則就會更加的麻煩，比如要如何訂一個工時的規則是既符合物流產線員工和產品行銷員工的，當沒辦法順利的定出好的文化和規則，也就很難在各種的部門間都發揮出他們最大的產值。而拆分公司就可以有效的解決公司的核心業務不明確的缺點。
• 微服務角度
  • 當架構越來越大，每個地方要求的方向越差越多，有的是需要API回得越快越好，有的是記錄要非常的小心，有的是需要多方去做溝通，此時如果要訂一個大家都遵守的寫程式邏輯會非常的麻煩，到底注重的要是速度？資料儲存的大小？同步異步的處理？有太多需要注意的了，因此通常到最後就只能什麼都抓什麼都重要，意思也就是什麼都不重要，因此拆分成微服務，每個服務就可以專注自己核心的商業邏輯去做優化。

需求的資源不一

• 公司角度
  • 對於橫跨上下游的公司來說，處理資源的分配是十分麻煩的一件事，比如物流應該是高資本低利潤、但風險低的部門，而行銷是低資本高利潤、但風險高的部門，這時候將兩者擺在同一間公司就會非常難分配資源，也會非常難以衡量兩者的績效。
• 微服務角度
  • 當架構越來越龐大也會發生一樣的事，就純粹以計算力來說好了，有的服務是需要穩定但少的運算資源，但有的服務是需要瞬間很多的運算資源，這時候要怎麼將這兩者的資源統合做調度是十分麻煩的，但假如分開成不同的微服務，就可以知道要怎麼妥善地去處理運算資源分配的問題。

明天會來聊聊微服務的缺點