前言

編程是一個還很年輕的行業(yè)，計算機從出現(xiàn)到現(xiàn)在也不過 70 年左右，因此我們總是在現(xiàn)存的行業(yè)中不斷尋找，探索，嘗試。從最初的單體架構(gòu)到之后的分布式架構(gòu)在到現(xiàn)在的微服務(wù)架構(gòu)，說明我們的確也在尋找更好的方法來構(gòu)建我們的應(yīng)用，從而提高客戶滿意度和開發(fā)效率。微服務(wù)不是被發(fā)明出來的，而是隨著區(qū)域領(lǐng)域設(shè)計，持續(xù)交付，按需虛擬化，小團隊自治協(xié)作，大型集群系統(tǒng)的流行等現(xiàn)實中總結(jié)出來的一種趨勢或模式。

[[419456]]

2014年馬丁·福勒(Martin Fowler)發(fā)表了以“微服務(wù)”為主題的文章后，短短數(shù)年，“微服務(wù)”已經(jīng)變的炙手可熱，成為大家所熟知的技術(shù)名詞，受到無數(shù)人的追捧。仿佛設(shè)計架構(gòu)不是“微服務(wù)”風(fēng)格的話，就在技術(shù)上有不足似的。

面對快速發(fā)展變化的IT行業(yè)，各種和微服務(wù)相關(guān)的技術(shù)和框架不斷涌現(xiàn)，架構(gòu)師和開發(fā)人員需要具備透過這些表象看清事物本源的能力。微服務(wù)架構(gòu)不僅涉及架構(gòu)和開發(fā)階段，還包含了測試、部署及運維等，它是一個完整的生命周期。隨著各種技術(shù)、框架和工具的豐富和完善，尤其是Service Mesh之類的技術(shù)的演進，Service Mesh的目標是要將微服務(wù)治理體系下沉為與業(yè)務(wù)無關(guān)的基礎(chǔ)設(shè)施。也就是說，在未來大家開發(fā)過程中可能不會意識到微服務(wù)的存在。但作為有追求的開發(fā)人員和架構(gòu)師，很有必要了解微服務(wù)的方方面面。

什么是微服務(wù)

在單體應(yīng)用中，開發(fā)者會在類、模塊、類庫的層面來設(shè)計功能屬性。為了解決各種各樣的復(fù)雜問題，軟件開發(fā)者一直致力于努力提供各種有效而及時的解決方案。然而面對日漸壯大的應(yīng)用，即便團隊成員受過專業(yè)的訓(xùn)練，可能也只是掙扎著盡量維持之前的節(jié)奏。糟糕的情況是，曾經(jīng)簡潔，穩(wěn)定的產(chǎn)品變得越來越難以維護和脆弱。無法按時發(fā)布新的版本或補丁，無法再為客戶持續(xù)交付更多價值。微服務(wù)解決了這類問題，它為我們提供了一種更好的持續(xù)交付業(yè)務(wù)影響的方式。在微服務(wù)應(yīng)用中，開發(fā)者的目標變成了可獨立部署的功能單元，圍繞這些功能單元設(shè)計功能屬性。

微服務(wù)是一系列自治服務(wù)的集合，每個服務(wù)只負責完成一塊功能，這些服務(wù)共同合作完成更加復(fù)雜的業(yè)務(wù)。

微服務(wù)核心原則

支撐微服務(wù)開發(fā)的五大架構(gòu)原則為：自治性、可恢復(fù)性、透明性、自動化和一致性。工程師在開發(fā)和運行時應(yīng)該結(jié)合這些原則做出合理的技術(shù)和決策。進而使系統(tǒng)更易于修改、擴展和穩(wěn)定。

1. 自治性你是否能夠修改一個服務(wù)并對其進行部署，而不影響其它任何服務(wù)。 —黃金法則我們已經(jīng)明確每個服務(wù)的操作和修改都是獨立于其他服務(wù)的。為了保證自治性開發(fā)者需要把服務(wù)設(shè)計的松耦合和可獨立部署。松耦合是指每個服務(wù)通過明確定義的接口或者事件消息來與其他服務(wù)進行交互?？瑟毩⒉渴鹗钦f不同的服務(wù)通常有多個不同的團隊并行開發(fā)，不要強迫所有的團隊按照同樣的設(shè)計步驟進行部署。理想情況下，大家想要的是服務(wù)夠快、頻繁改動發(fā)布。
2. 可恢復(fù)性微服務(wù)與生俱來具備故障隔離機制：獨立部署運行的微服務(wù)在應(yīng)用或基礎(chǔ)設(shè)施出現(xiàn)故障后，故障只會影響到整個系統(tǒng)的一部分功能。盡管這樣，微服務(wù)還是會存在多點故障的問題。比如，在異步交互及熔斷器和超時等。
3. 透明性不管在什么時候，系統(tǒng)都應(yīng)該是透明的，可觀測的，這樣當故障發(fā)生時不但能及時的發(fā)現(xiàn)問題，更可能會盡快的診斷解決問題。
4. 自動化通過開發(fā)大量的服務(wù)來緩解應(yīng)用不斷變大所帶來的的痛苦，這貌似有悖常理。相對于單體應(yīng)用，微服務(wù)確實是一種更加復(fù)雜的架構(gòu)。開發(fā)者需要使用自動化來保證部署和運維過程中的正確性。微服務(wù)架目前流行的兩種趨勢，一種是DevOps 基礎(chǔ)設(shè)施即代碼，另一種是通過API進行編程的基礎(chǔ)設(shè)施環(huán)境(AWS、Azure)。
5. 一致性開發(fā)者應(yīng)該圍繞業(yè)務(wù)概念來組織服務(wù)和團隊，只有這樣服務(wù)和團隊的內(nèi)聚性才能更高。微服務(wù)架構(gòu)應(yīng)該偏向于縱向拆分。每個服務(wù)應(yīng)該與一個獨立的業(yè)務(wù)功能匹配，并將相關(guān)的技術(shù)層內(nèi)容封裝在一起。

微服務(wù)優(yōu)勢

1. 技術(shù)選型靈活微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。在一個有多個服務(wù)相互協(xié)作的系統(tǒng)中，可以在不同的服務(wù)中使用最合適該服務(wù)的技術(shù)。
2. 容錯當某一功能發(fā)生故障時，在單一進程的傳統(tǒng)架構(gòu)下，故障很有可能在進程內(nèi)擴散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機制實現(xiàn)應(yīng)用層面的容錯。
3. 擴展單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當應(yīng)用的不同組件在擴展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨立進行擴展。
4. 簡化部署在有幾百萬行代碼的程序中，即使修改一行代碼，也需要重新部署整個應(yīng)用程序才能發(fā)布該變更。這種部署影響大風(fēng)險高。在微服務(wù)架構(gòu)中，各個服務(wù)部署是獨立的，這樣就可以更快的對特定的代碼進行部署，如果真出了問題，也只會影響一個服務(wù)，并且容易快速回滾。
5. 與組織結(jié)構(gòu)相匹配我們經(jīng)歷過太多由于團隊和代碼庫過大所引發(fā)的問題。微服務(wù)可以很好的將架構(gòu)和組織進行匹配，避免出現(xiàn)過大的代碼庫，從而獲得理想的團隊大小及生產(chǎn)力。服務(wù)的所有權(quán)也可以在團隊之間遷移，從而避免異地團隊的出現(xiàn)。我們可以結(jié)合康威定律進行合理的調(diào)整：第一定律 組織溝通方式會通過系統(tǒng)設(shè)計表達出來。第二定律 時間再多一件事情也不可能做的完美，但總有時間做完一件事情。第三定律 線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性。第四定律 大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。
6. 可組合性分布式系統(tǒng)和面向服務(wù)架構(gòu)的主要好處是易于重構(gòu)已有功能。而在微服務(wù)架構(gòu)中，根據(jù)不同的目的可以通過不同的方式使用同一功能，在考慮客戶如何使用該軟件時尤為重要。
7. 可替代性我們在工作中可能接觸過一些龐大丑陋的遺留系統(tǒng)，他們無人敢碰，但是對公司業(yè)務(wù)至關(guān)重要。為什么這些系統(tǒng)直到現(xiàn)在還沒有被取代?其實你很清楚：工作量大，且風(fēng)險極高。想想看，在單體應(yīng)用中你是否會在一天內(nèi)刪除上百行代碼且確信不會引發(fā)問題?使用微服務(wù)架構(gòu)的團隊可以在需要時輕易重寫服務(wù)，或者刪除不在使用的服務(wù)。當一個代碼庫只有幾百行時，也不會對它有太多情感上的依賴，所以很容易替換它。

微服務(wù)挑戰(zhàn)

設(shè)計挑戰(zhàn)

1. 設(shè)計挑戰(zhàn)劃定微服務(wù)范圍需要業(yè)務(wù)領(lǐng)域知識。每個微服務(wù)都只負責一個功能，識別這些功能需要豐富的業(yè)務(wù)領(lǐng)域知識。開發(fā)者對問題領(lǐng)域理解不充分或錯誤的理解，將導(dǎo)致錯誤的設(shè)計決定。也就是我們所說的范圍邊界劃分不清晰或不合理，可能給下游業(yè)務(wù)造成更高的代價。服務(wù)契約的維護每個微服務(wù)應(yīng)該對外暴露一個契約(接口)用于定義它所期望接受和返回的消息。一個良好的契約應(yīng)該具備以下特點：完整、簡潔、可預(yù)測。
2. 運維挑戰(zhàn)工程師面對的微服務(wù)兩大運維挑戰(zhàn)：可觀測性和多點故障?？捎^測性難實現(xiàn)的原因在于工程師需要對應(yīng)用整體有所了解，把每個服務(wù)所生產(chǎn)的數(shù)據(jù)進行關(guān)聯(lián)和匯總。如果開發(fā)者提前認定服務(wù)存在的缺陷，那么就能更好的提醒自己如何進行設(shè)計和監(jiān)控，而不會等到故障出現(xiàn)時才大吃一驚。
3. 微服務(wù)是多個團隊設(shè)計在規(guī)模較大的組織中，通常是由多個團隊來開發(fā)和運行微服務(wù)應(yīng)用。每個團隊負責不同的微服務(wù)，他們有自己的目標、工作方式和交付周期。如果開發(fā)者還需要和其他獨立的團隊協(xié)調(diào)時間表和優(yōu)先級，就很難設(shè)計出一個內(nèi)聚的系統(tǒng)。

微服務(wù)設(shè)計

• 單一職責原則把因相同原因而變化的東西聚合在一起，把因不同原因而變化的東西分離出來。這就是我們常說的內(nèi)聚性。
• 服務(wù)邊界一個微服務(wù)應(yīng)該可以在兩周內(nèi)完全重寫，這個經(jīng)驗法則在某些特定的場合下是有效的。 ——復(fù)雜度拆分大家通常能夠意識到什么是“過大”，如果你不在感覺到你的代碼庫過大，可能他就是足夠小了，足夠小即可。 ——最小原則拆分最小拆分原則需要注意的一個問題是：服務(wù)越小雖然獨特性的好處顯而易見，但是管理大量服務(wù)也會越發(fā)的復(fù)雜。如果代碼庫過大，當下團隊無法正常運維，那么應(yīng)該將其拆分成小的。 ——組織匹配度拆分然而一個常見的拆分誤區(qū)是通過代碼庫的大小或代碼行數(shù)來衡量。因為服務(wù)代碼存在依賴項，每個依賴項又會包含很多代碼。

總結(jié)

希望到目前為止你已經(jīng)了解了什么是微服務(wù)、它有什么特性和好處。架構(gòu)師的一個重要職責是，確保團隊有共同的技術(shù)愿景，以幫助我們向客戶交付他們想要的系統(tǒng)。在這個編程的行業(yè)還很年輕的時代，如何在現(xiàn)存的行業(yè)中尋找合理的技術(shù)解決方案，做出正確的決策，這也是架構(gòu)師這一角色難做好的原因之一，我們不是醫(yī)生也不是電工，我們處在行業(yè)的中間地帶，因此很耐被理解我們到底在做什么，因為很多時候我們也不清楚自己到底處在什么位置上。

規(guī)則對于智者來說是指導(dǎo)，對于愚蠢者來說是遵從。 每種架構(gòu)的演進或者說每種技術(shù)的進步都伴隨著相應(yīng)的契約規(guī)則。微服務(wù)價值體現(xiàn)在松耦合、高內(nèi)聚。我們應(yīng)該了解和追尋技術(shù)發(fā)展的源動力。因為成功要靠不斷的取舍來實現(xiàn)。