知識星球導讀：本文作者首先簡單介紹了微服務的優點和缺點。然後論述了使用微服務的正確姿勢。最後透過一個簡單的示例介紹了使用Spring Boot如何實現微服務。
在本文中，我們將討論微服務的優缺點，以便您可以做出更好的決定。在此之後，我們將透過一個例子來瞭解微服務架構。
硬體的進步幅度已經趕上了應用程式變複雜的腳步。然而卻沒有趕上網際網路流量變化的腳步。 因此需要改變架構和web介面，我們有許多技術來解決這個問題，現在後端單體程式幾乎不存在。
我們將在這裡討論微服務的優缺點。
優點：
-
您可以使用各種語言的最新技術棧。
-
可以使用應用隔板（Bulkhead），這樣如果一個系統失效，其他系統還能有效服務。
-
動態可擴充套件
-
組合而成的應用程式， 釋出週期不會很長。
-
應用程式將是一組獨立的系統，部署過程將更加平滑。
-
有助於有效利用人力和技術資源。
缺點：
-
這對於小型應用來說非初始成本非常高。
-
整合和測試工作可能會增加。
-
有時開發者會抱怨重覆的工作。
-
增加服務API可能非常複雜。 記憶體消耗可能很高
取用Martin Fowler的話：
我們聽到的一個合理的論點是，你不應該從微服務架構開始。取而代之的是單體應用，保持它的模組化，一旦單體應用出現問題，就將它分割成微服務
如果你已經開始使用微服務，那麼它的優勢就很明顯了。如果應用程式變得龐大而複雜，那麼隨著應用程式逐漸模組化，然後轉向微服務。因為微服務在技術，工作量和架構設計水平方面非常的要求很高。
我們將建立一個專案來演示。 微服務是一種架構風格，其實現由許多框架支援，即。Dropwizard，Vertx，Spring Boot，Restlet，Spark + Unirest（REST客戶端，Spark本身不提供REST客戶端）等。這裡我們將使用Spring引導。 這是微服務最流行的框架，因為我們知道它由Spring提供支援。
在這個專案中，我們將使用Eureka伺服器，它僅僅是一個服務註冊中心實現。 在這種情況下，每個微服務都被註冊，客戶端透過查詢Eureka伺服器來查詢相關的微服務。 我們試圖模仿這裡的真實世界場景，其中Eureka伺服器和不同的微服務分別部署。
初始化Eureka服務
對於我們的演示目的，我們僅僅使用Eureka作為我們的服務註冊伺服器。 為此，您只需使用正確的依賴關係併在應用程式yaml或屬性檔案中指定Eureka屬性。
Eureka POM
application.yaml
以下是將您的應用程式主要配置
一旦我們啟動應用程式，Eureka伺服器將顯示所有已註冊和可用服務的詳細資訊。
目前沒有任何已註冊的服務，因此您會看到警告。
微服務客戶端
我們將定義兩個簡單的專案：員工服務和僱主服務。 這兩個服務將向Eureka伺服器註冊。 這些專案的核心將是它的應用程式屬性，它們將定義它們將在伺服器上註冊的名稱和其他引數。
員工服務
僱主服務
一旦我們啟動了程式，他們就會在Eureka上註冊。
請註意，警告已消失。
使用已釋出的微服務
客戶都註冊了不同的名稱。 這些名稱將用於在其他客戶端查詢服務。 在我們的例子中，EMPLOYEE-SERVICE傳回靜態資料。 此資料在EMPLOYER SERVICE中獲取並顯示。
員工服務
我們只有2個預定義的資料集，我們將僅從此集傳回。
僱主服務
請註意僱主服務如何訪問員工服務。 它沒有使用任何主機或埠。 基於服務名稱，它設法找到並使用該服務。
輸出
結論
在這裡我們看到了基於Spring Boot的微服務最小功能實現。 這裡服務與伺服器配置和部署非常隔離。
您可以從GitHub Repository下載完整的程式碼[1]
本文作者Rahul，由方圓翻譯。轉載譯文請註明出處，技術原創及架構實踐文章，歡迎透過公眾號選單「聯絡我們」進行投稿。
文中連結：
[1] https://github.com/pavansolapure/opencodez-samples/tree/master/microservices
相關閱讀：
微博開源的Motan RPC最新進展：新增跨語言及服務治理支援
模組化還是微服務 – 為什麼說大部分團隊微服務化都走入了陷阱
活動預告：
6 月 1 ~ 2 日，GIAC 全球網際網路架構大會將於深圳舉行。GIAC 是高可用架構技術社群推出的面向架構師、技術負責人及高階技術從業人員的技術架構大會。今年的 GIAC 已經有騰訊、阿裡巴巴、百度、今日頭條、科大訊飛、新浪微博、小米、美圖、Oracle、鏈家、唯品會、京東、餓了麼、美團點評、羅輯思維、ofo、曠視、LinkedIn、Pivotal等公司專家出席。
本期 GIAC 大會上，部分精彩的議題如下：
參加 GIAC，盤點2018最新技術。點選“閱讀原文”瞭解大會更多詳情
