我們是否在構建過於龐大的系統，比實際需要更大的系統，thoughtworks的首席顧問james lewis在goto berlin大會上談論「微服務——自適應的架構和組織」時以此開始了他的演講。有示例表明所有制總體成本超過90%發生在乙個系統啟動之後。還有很多專案示例顯示作為乙個產業我們把大量的金錢花在了構建非常大的、複雜的並且根本沒有用的系統上。
\u0026#xd;\n
james在大型組織中的經驗表明，傳統的構建系統的方式是將所有的功能放到乙個大的應用程式中，使用乙個大的資料庫，但是這樣做產生的問題引導著他進入了另一種構建系統的方式，新的方法將整個業務分離成更小的部分，正如微服務那樣，每乙個部分有它們自己的資料庫。
\u0026#xd;\n
對於他而言，之所以能夠採用這種方式首先是源於六邊形（hexagonal）業務能力，參考了alistair cockburn的
hexagonal架構。乙個單獨的業務能力或者功能以及它自己的資料形成了乙個六邊形，乙個使用ddd條款的有邊界的上下文。然後所有的這些六邊形會一起被放到乙個更大的六邊形裡面，最終形成了乙個系統。
\u0026#xd;\n
其次，他關注為所有的服務構建乙個統一的介面。在構建隔離系統時一種常見的整合技術是直接整合資料庫訪問。這種方式的問題是，它與系統的不同部分緊耦合，邏輯和資料很容易分散到系統的各個部分，讓它變得難以**變化的影響。james喜歡使用在web上應用地很成功的整合技術，它們基於http、html和超**，並使用rest進行通訊。除了rest之外，james還發現了兩種非常有用的標準應用程式協議，它們是atom 和 atompub。
\u0026#xd;\n
james相信所有的這些小服務都應該遵循單一職責原則（single responsibility principle），同時該原則應該應用到抽象的每乙個層次，從物件到子系統業務能力，到形成系統的各個方面。
\u0026#xd;\n
最後，james談到了可伸縮性。構建乙個單獨的支援所有功能的大系統使得它難以或者說不可能擴充套件系統的不同部分。即使系統中某些部分負載很高，而其他部分負載非常低，它們也必須以同樣的容量執行。如果使用的是微服務，那麼它們能夠被部署到不同的伺服器上，使用不同數量的伺服器。另一種好處是不同的服務可以基於不同的平台實現。使用很多小服務的另乙個至關重要的因素是自動地監控和部署，例如使用可程式設計的基礎設施。過去這幾年虛擬化、基礎設施即服務（infrastructure as a service，iaas）的進展讓這些成為了可能。
\u0026#xd;\n
2023年的goto berlin大會是goto大會首次在berlin舉行，本次大會有超過400位參會者和大約80位講師。
\u0026#xd;\n
檢視英文原文：goto berlin: microservices as an alternative to monoliths
微服務 微服務簡介
什麼是微服務 顧名思義，就是粒度較小的服務，不再侷限於系統與系統之間的藉口呼叫，也不侷限於某種具體的服務形式。系統中凡是可被復用的功能模組都可以被 服務化 轉變為 服務 這些服務可以對外暴露，也可能僅限於再系統內部使用。由於服務數量更多，粒度更小，因此管控難度會更大，對效能的要求也更高。微服務的好處...
使用micro建立微服務
micro是乙個工具集，用來幫助開發者建立和管理微服務。它包括兩部分 另外go plugins作為一組外掛程式，在開發過程中也是必要的。通過外掛程式，我們在服務發現 非同步訊息和傳輸協議等方面有了更多的選擇。go micro的設計目標是簡化微服務的開發和分布式系統的建立。在golang 1.14以後...
為什麼使用微服務
1.單機服務 此時我們就多加了幾台web伺服器，從單機變成了乙個集群，甚至我們可以寫乙個指令碼，當web伺服器壓力過大時動態增加web伺服器。這下web伺服器的壓力不大了，我們就這樣安穩的過上了幾個月。然而有一天伺服器又出問題了 先是mysql伺服器cpu標高，然後是web伺服器宕機。此時我們會發現...