微服務 spring boot 譯<二>

Microservices for Java Developers

What Can You Expect from This Book?

本書面向對開發微服務感興趣的Java開發人員和架構師。咱們開始從高層的結構來介紹微服務，須要準備哪些功能設施來成功的部署微服務。不幸的是，僅僅使用新技術並不能完美地解決分佈式系統的問題。咱們來看看其中的一些例子，以及成功的公司如何爲微服務所作的工做，包括文化、組織結構和市場保證。而後，咱們深刻研究了幾個用於實現微服務的Java框架。隨附的源代碼倉庫能夠在GitHub（https://github.com/redhat-developer/microservices-by-example-source）上找到。一旦咱們在微服務中髒了手，咱們將回到空中，討論有關部署、集羣、failover 和  與 Kubernetes如何在這些領域提供解決方案的問題。而後，咱們將經過Docker、Kubernetes和netflixOSS的一些親身體驗的例子來展現它們爲雲原生微服務體系結構帶來的強大功能。咱們結束了對主題的想法，沒法涵蓋在這本小書中，但一樣重要的，如配置，日誌，和連續交付。

微服務不只僅是一種技術上的討論。微服務的實施植根於複雜適應理論、服務設計、技術進化、領域驅動設計、依賴思惟、承諾理論等背景。他們都彙集在一塊兒，讓一個組織的人真正展示敏捷，響應，學習行爲，在一個快速發展的商業世界保持競爭力，讓咱們仔細看看。

You Work for a Software Company

軟件真的在吞噬世界。企業正慢慢開始意識到這一點，這一現象有兩個主要驅動因素：經過高質量的服務提供價值，以及技術的快速商業化。這本書主要是以一個動手，按例格式驅動。可是，在咱們深刻研究這項技術以前，咱們須要正確地安排好舞臺，瞭解發揮做用的各類力量。近年來，咱們一直在不厭其煩地談論如何使企業變得靈活，但咱們須要充分理解這意味着什麼。否則的話，這不過是你們都在掩飾的陳詞濫調罷了。

The Value of Service

100多年來，咱們的商業市場一直致力於提高產品質量，並推進消費者購買這些產品：辦公桌、微波爐、汽車、鞋子等等。這種「生產者主導的」經濟背後的想法來自亨利福特的想法，「若是你能以低成本生產大量的產品，市場將幾乎是無限的。」要作到這一點，你還須要一些單向渠道，直接面向大衆，說服他們，他們須要這些產品，他們的生活會變得更好。在20世紀的大部分時間裏，這些單向渠道以電視廣告、報紙雜誌廣告和高速公路廣告牌的形式存在。然而，這種以生產者爲主導的經濟已經被顛覆了，由於市場已經被產品徹底飽和了(你須要多少部手機/汽車/電視？)。此外，互聯網和社交網絡正在改變企業與消費者互動的方式(或者更重要的是，消費者與消費者互動的方式)。

做爲消費者，社交網絡使咱們可以更自由地與彼此和與咱們作生意的公司分享信息。咱們對朋友、家人和其餘人的信任超過了咱們對市場營銷部門的信任。這就是爲何咱們在社交媒體上選擇餐館、酒店和航空公司的緣由。咱們以評論、推特、股票等形式提供的正面反饋，能夠對公司的品牌產生正面的支持，而咱們的負面反饋也能夠很容易地、很是容易地給出正面的反饋，迅速摧毀一個品牌。現在，企業和消費者之間存在着史無前例的強大的雙向信息流，企業很難跟上不擁有本身品牌的影響。

現代工業企業正在學習，他們必須培養他們與客戶的關係(使用雙向溝通)，以理解如何爲他們帶來價值。公司經過服務、客戶體驗和反饋提供持續的對話來作到這一點。客戶根據哪一種服務帶來的價值和良好的體驗來選擇使用哪一種服務和支付哪一種服務。以Uber爲例，它自己不擁有任何庫存，也不銷售產品。我坐在別人的車裏沒有任何價值，但一般我是想找個有價值的地方(好比商務會議)。經過這種方式，優步和我經過使用它的服務創造了價值。展望將來，企業須要專一於爲消費者提供有價值的服務，而技術將經過數字服務推進這些服務。

Commoditization of Technology

技術經歷了一個相似於經濟、生物學和法律的從繁榮到蕭條的週期。它帶來了巨大的創新，好比蒸汽機、電話和電腦。然而，在咱們競爭激烈的市場中，改變遊戲規則的創新須要大量的投資和積累，才能迅速從各自的市場中獲利。這帶來了更多的競爭、更大的產能和不斷降低的價格，最終使一度創新的技術成爲一種商品。在這些商品上，咱們繼續創新和差別化，週期也在繼續。這種商品化把咱們從大型機將我的電腦變成咱們如今所稱的「雲計算」，這是一項爲咱們帶來商品計算的服務，幾乎沒有前期的資本支出。在雲計算之上，咱們正在以數字服務的形式帶來新的創新。

 

開源也是技術領域的領頭羊。按照商品化的曲線，開源是開發者能夠挑戰專有供應商的地方，他們能夠經過構建和創新那些曾經只提供(沒有提供源代碼)且許可證成本很高的軟件。這促使社區構建諸如操做系統(Linux)、編程語言(GO)、消息隊列(ApacheActiveMQ)和Web服務器(Httpd)之類的東西。即便是最初拒絕開放源碼的公司也開始經過開源他們的技術併爲現有社區作出貢獻。隨着開源和開放生態系統成爲規範，咱們開始看到許多軟件技術創新直接來自開源社區(例如ApacheSPark、Docker和Kubernetes)。

Disruption

這兩個因素的結合，即服務設計和技術發展，正在下降任何有良好想法的人開始試驗和嘗試創建新服務的進入門檻。您能夠學習編程、使用高級框架和利用隨需應變計算。你能夠在社交網站、博客上發表文章，並免費與潛在用戶進行雙向對話。隨着咱們商業市場的流動性，任何一家週末以上的初創企業均可能讓一家傳統公司破產。

這一事實令大多數首席信息官和首席執行官感到懼怕。隨着軟件迅速成爲公司構建數字服務、體驗和差別化的機制，許多公司意識到它們必須成爲各自垂直領域的軟件公司。大規模外包和將IT視爲商品或成本中心的時代已經一去不復返了。爲了讓公司保持真正的競爭力，他們必須接受軟件做爲一個不同凡響的東西，爲了作到這一點，他們必須擁抱組織的敏捷性。

Embrace Organization Agility

20世紀工業時代的公司並非爲了敏捷而創建的。它們的創建是爲了最大限度地提升效率，減小過程當中的可變性，消除工人的創造性思惟，並像組織裝配線同樣將工人放入箱內。它們就像一臺機器，用來接收輸入，應用一個高度調整的過程，並建立輸出。它們採用自上而下的分層管理結構，以便於這種機器式的思考。更換機器須要18個月的計劃週期。來自邊緣的信息要通過多層管理和翻譯才能到達頂層，在那裏做出決策並將其傳回。這種組織方法在建立產品和試圖從流程中獲取每一點效率時很是有效，但不適用於交付服務。

客戶不適合放在盒子裏或過程上。他們想何時來就何時來。他們想要的是客戶服務，而不是自動電話系統。他們要菜單上沒有的東西。他們須要輸入一些表格上沒有的內容。顧客想要方便的服務，若是他們必須等待的話，他們會生氣的。

這意味着咱們面向客戶的服務須要考慮可變性。他們須要可以對意外事件作出反應，這與效率不符。客戶但願經過您爲他們提供的服務進行對話，若是該服務不足以解決他們的需求，您須要快速的反饋，說明是什麼幫助解決了他們的需求或阻礙了他們。這個反饋能夠被服務的維護人員用來快速地調整服務和改變交互模型，以更好地適應用戶。你不能等待決策浮出水面，並貫穿18個月的計劃週期；你須要快速作出決定，你的信息在你的業務的邊緣。您須要自主的、目標驅動的、自我組織的團隊，他們負責向他們的客戶(付費客戶、業務合做夥伴、同行團隊等)提供引人注目的體驗。快速反饋週期、自主團隊、共同目標和對話是組織必須接受的先決條件，以便可以在後工業化、未知、未知的業務干擾中導航和生存。

沒有一本關於微型服務的書是完整的，除非引用康韋的定律：「設計系統的組織...必須產生複製這些組織的通訊結構的設計。」

要構建敏捷軟件系統，咱們必須從構建敏捷組織結構開始。這種結構將簡化咱們提供微服務所需的前提條件，可是咱們使用什麼技術呢？構建分佈式系統很困難，在接下來的部分中，咱們將研究在構建和設計這些服務時必須牢記的問題。

 

原文：

做者源碼：https://github.com/redhat-developer/microservices-by-example-source