本文為大家介紹了5個(gè)遷移到微服務(wù)架構(gòu)所需做的準(zhǔn)備步驟，包括如何劃分微服務(wù)，微服務(wù)和組織結(jié)構(gòu)間的誤解，如何劃分組織架構(gòu)，以及在實(shí)現(xiàn)微服務(wù)架構(gòu)中需要盡早考慮的一些問題，值得大家參考
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、雅安服務(wù)器托管、營銷軟件、網(wǎng)站建設(shè)、江都網(wǎng)站維護(hù)、網(wǎng)站推廣。
時(shí)至今日，微服務(wù)相關(guān)的話題不勝枚舉，上百次的會(huì)議，在線討論以及相關(guān)文章。你可以假設(shè)大家已經(jīng)認(rèn)識(shí)到其優(yōu)點(diǎn)以及與之俱來的風(fēng)險(xiǎn)。然而，有很多組織沒有事先準(zhǔn)備就邁入這個(gè)潮流了。自然，這也就導(dǎo)致了在架構(gòu)實(shí)現(xiàn)過程中的失敗。
有一位智者曾經(jīng)說過，“對(duì)于商業(yè)中所應(yīng)用的任何技術(shù)而言，有2條規(guī)則，其一，將自動(dòng)化應(yīng)用于高效的運(yùn)維上才能增加效率；其二，將自動(dòng)化應(yīng)用于低效的運(yùn)維反而會(huì)降低效率?！蔽艺J(rèn)為這種哲學(xué)對(duì)微服務(wù)而言亦行之有效。如果你的組織沒有為此準(zhǔn)備就貿(mào)然遷移，很可能會(huì)招致失敗。以上就是本文的出發(fā)點(diǎn)，我將為大家?guī)碓趯?shí)現(xiàn)微服務(wù)架構(gòu)前需要準(zhǔn)備的5個(gè)關(guān)鍵步驟。
從繪圖入手
在開發(fā)特定的微服務(wù)時(shí)，許多開發(fā)者都會(huì)犯同一個(gè)錯(cuò)誤：直接寫代碼?；蛟S，這可能就是你能夠犯的最嚴(yán)重的錯(cuò)誤了。誠然，對(duì)于一個(gè)服務(wù)而言，你可能會(huì)獲得成功，但是隨著服務(wù)數(shù)量的上升，所有事情都會(huì)變得一團(tuán)亂。
和其它產(chǎn)品一樣，它也需要被創(chuàng)造，需要以設(shè)計(jì)作為初始步驟。將團(tuán)隊(duì)匯聚到桌子周圍，自由地在紙上（或者白板）繪制服務(wù)。首先，找出你所構(gòu)建的應(yīng)用的main函數(shù)。然后，自頂向下地將它分解成最小單元。最后，找出不同單元的互聯(lián)通性。這些功能將會(huì)成為你的微服務(wù)。
比如，在一款圖書預(yù)覽應(yīng)用中，其主要的功能就是比較不同的圖書。然而，也有許多其他功能需要開發(fā)，例如創(chuàng)建用戶履歷，評(píng)分，評(píng)論，圖書數(shù)據(jù)庫等。識(shí)別每個(gè)功能，是將它們轉(zhuǎn)為微服務(wù)的關(guān)鍵。
整個(gè)過程將會(huì)持續(xù)超過一天時(shí)間，并且需要多次迭代直至完美。當(dāng)然，你將需要從許多不同部門的人員手中獲得輸入，以確保能夠知曉其視角和觀點(diǎn)，并確保你不會(huì)遺漏任何系統(tǒng)功能。
微服務(wù)并不是組織結(jié)構(gòu)
根據(jù)你所在公司的組織結(jié)構(gòu)定義微服務(wù)，這似乎是很自然的。如果你正在構(gòu)建單體（monolithic）應(yīng)用，這或許真是一個(gè)恰當(dāng)?shù)慕鉀Q方案。但是，在實(shí)現(xiàn)微服務(wù)架構(gòu)時(shí)，它可能就是一個(gè)錯(cuò)誤的決定了。
也許，這對(duì)于銷售部門或客戶服務(wù)是可行的，但是許多組織只有一個(gè)部門處理所有的數(shù)據(jù)庫。因此，為所有數(shù)據(jù)庫創(chuàng)建一個(gè)微服務(wù)將會(huì)導(dǎo)致單點(diǎn)故障。而沒有單點(diǎn)故障，則是微服務(wù)的關(guān)鍵特性之一。
你希望通過服務(wù)實(shí)現(xiàn)的一些功能可能會(huì)涉及幾個(gè)組織部門，或者，你可能將會(huì)需要為一個(gè)部門構(gòu)建許多微服務(wù)。總結(jié)一下，你需要將架構(gòu)聚焦于你想要提供的服務(wù)，而非你們公司的組織結(jié)構(gòu)。
創(chuàng)建合適的組織結(jié)構(gòu)
轉(zhuǎn)變到一個(gè)全然不同的組織架構(gòu)，能夠滿足公司在管控活動(dòng)上變化的需要。之前2個(gè)步驟關(guān)注于應(yīng)用的設(shè)計(jì)，以便能夠?yàn)樽罱K用戶提供正確的功能?，F(xiàn)在，是時(shí)候確保對(duì)于新的架構(gòu)而言，你擁有恰當(dāng)?shù)倪\(yùn)維支持了。
你將不得不放棄原有的部門結(jié)構(gòu)，并使團(tuán)隊(duì)關(guān)注于某個(gè)微服務(wù)。這意味著這些團(tuán)隊(duì)將由擁有不同技能的成員組成，如系統(tǒng)分析師、UX/UI設(shè)計(jì)師、后端工程師、前端工程師等。如此一來，團(tuán)隊(duì)就能夠徹底負(fù)責(zé)它們的項(xiàng)目（微服務(wù)）——從開發(fā)部署到運(yùn)維、監(jiān)控和管理。反過來，由于團(tuán)隊(duì)覺得自己擁有這個(gè)產(chǎn)品，因此將提升其創(chuàng)建產(chǎn)品的積極性。
團(tuán)隊(duì)的規(guī)模視公司/項(xiàng)目的總體人數(shù)而定；當(dāng)然，根據(jù)專家的建議，比較理想的規(guī)模是每個(gè)團(tuán)隊(duì)8-10人。和單體架構(gòu)不同，微服務(wù)架構(gòu)使得你能夠根據(jù)業(yè)務(wù)的增長來擴(kuò)展團(tuán)隊(duì)規(guī)模。
當(dāng)然，所有團(tuán)隊(duì)將會(huì)（需要）積極配合，以最終促成整個(gè)項(xiàng)目。這便是這種結(jié)構(gòu)的主要好處，使我們能夠盡可能快地向市場(chǎng)交付產(chǎn)品。
性能和可靠性同樣重要
切換到微服務(wù)架構(gòu)的整體想法，便是使得創(chuàng)建的最終產(chǎn)品相比于單體應(yīng)用而言擁有更好的性能，更佳的穩(wěn)定性（例如，更低的下線風(fēng)險(xiǎn)），同時(shí)可以更快地交付市場(chǎng)。
將改進(jìn)性能作為設(shè)計(jì)的一部分是很重要的，這將確保潛在問題能夠盡早被考慮。通常，（性能）問題都源自微服務(wù)設(shè)計(jì)主要考慮功能。然而，如果在更大的服務(wù)下，服務(wù)崩潰或者變得很慢，那么它就沒什么用了。每個(gè)服務(wù)應(yīng)該擁有2-3個(gè)替代機(jī)制，當(dāng)下層資源失敗時(shí)，它便可以繼續(xù)運(yùn)作。當(dāng)其中一個(gè)機(jī)制無法在可接受時(shí)間窗口內(nèi)響應(yīng)時(shí)，服務(wù)也需要做到快速切換。
在前期考慮讓服務(wù)支持更大的負(fù)載變動(dòng)，你的應(yīng)用將能夠應(yīng)對(duì)實(shí)際挑戰(zhàn)，你將領(lǐng)先市場(chǎng)，當(dāng)然這也是你在第一時(shí)間考慮切換到微服務(wù)的主要原因！
變更先行
忽略應(yīng)用的變化是不切實(shí)際的。開發(fā)者一直在增加和移除功能，變更代碼，替換應(yīng)用的核心元素等，這在微服務(wù)應(yīng)用中更甚。更確切地說，微服務(wù)就是持續(xù)演進(jìn)的。
當(dāng)你每天需要處理多次代碼升級(jí)時(shí)，最好接受一個(gè)觀點(diǎn)：變更是持續(xù)的，而非對(duì)于穩(wěn)定狀態(tài)的一次偶然性中斷。一旦你認(rèn)知到這一點(diǎn)，你將意識(shí)到一開始便整合變更的靈活性需求的重要性。確保應(yīng)用一直正常工作的一種方式便是準(zhǔn)備服務(wù)API，這樣微服務(wù)間便可繼續(xù)通信，即使它們已被改變。另外，你還需要引入版本控制，以允許服務(wù)同時(shí)開放新舊接口。
另一方面，數(shù)據(jù)存儲(chǔ)的演進(jìn)是一個(gè)更大的挑戰(zhàn)。改進(jìn)數(shù)據(jù)庫模式（schema），使其支持新的功能，傳統(tǒng)觀點(diǎn)中，這是應(yīng)用升級(jí)時(shí)最難處理的部分，微服務(wù)并不會(huì)使其變得更加簡單。然而，單就增加新的域且不破壞現(xiàn)有結(jié)構(gòu)這一點(diǎn)而言，NoSQL數(shù)據(jù)庫會(huì)更加靈活。如果你希望你的數(shù)據(jù)存儲(chǔ)需求持續(xù)演進(jìn)（誰不希望呢？），那么你應(yīng)該將可演化的數(shù)據(jù)存儲(chǔ)作為微服務(wù)設(shè)計(jì)的努力方向之一。
在遷移到微服務(wù)架構(gòu)時(shí)，做適當(dāng)?shù)臏?zhǔn)備是整個(gè)項(xiàng)目成功的關(guān)鍵因素，這一點(diǎn)我們可以認(rèn)同。只有經(jīng)過仔細(xì)的準(zhǔn)備，創(chuàng)新設(shè)計(jì)思維，并且具備合適的運(yùn)維和管理結(jié)構(gòu)，你才能收獲微服務(wù)帶來的所有好處！
1.將復(fù)雜的業(yè)務(wù)拆分成多個(gè)小的業(yè)務(wù),每個(gè)業(yè)務(wù)拆分成一個(gè)服務(wù),將復(fù)雜的問題簡單化。利于分工,降低新人的學(xué)習(xí)成本。
2.微服務(wù)應(yīng)用的一個(gè)最大的優(yōu)點(diǎn)是,它們往往比傳統(tǒng)的應(yīng)用程序更有效地利用計(jì)算資源。這是因?yàn)樗鼈兺ㄟ^擴(kuò)展組件來處理功能瓶頸問題。這樣一來,開發(fā)人員只需要為額外的組件部署計(jì)算資源,而不需要部署一個(gè)完整的應(yīng)用程序的全新迭代。最終的結(jié)果是有更多的資源可以提供給其它任務(wù)。
3.微服務(wù)應(yīng)用程序的另一個(gè)好處是,它們更快且更容易更新。當(dāng)開發(fā)者對(duì)一個(gè)傳統(tǒng)的單體應(yīng)用程序進(jìn)行變更時(shí),他們必須做詳細(xì)的QA測(cè)試,以確保變更不會(huì)影響其他特性或功能。但有了微服務(wù),開發(fā)者可以更新應(yīng)用程序的單個(gè)組件,而不會(huì)影響其他的部分。測(cè)試微服務(wù)應(yīng)用程序仍然是必需的,但它更容易識(shí)別和隔離問題,從而加快開發(fā)速度并支持DevOps和持續(xù)應(yīng)用程序開發(fā)。
4.微服務(wù)架構(gòu)有助于新興的云服務(wù),如事件驅(qū)動(dòng)計(jì)算。類似AWS Lambda這樣的功能讓開發(fā)人員能夠編寫代碼處于休眠狀態(tài),直到應(yīng)用程序事件觸發(fā)。事件處理時(shí)才需要使用計(jì)算資源，而企業(yè)只需要為每次事件,而不是固定數(shù)目的計(jì)算實(shí)例支付。
缺點(diǎn)1.整體復(fù)雜度更高,微服務(wù)根本上說是一個(gè)分布式系統(tǒng)。開發(fā)者需要選擇和實(shí)現(xiàn)基于消息或者 RPC 的進(jìn)程間通信機(jī)制。雖然這個(gè)有很多框架可供選擇,并不需要從頭實(shí)現(xiàn)。但是整體上的代碼復(fù)雜度是提高了。
2.微服務(wù)架構(gòu)上每個(gè)業(yè)務(wù)有自己的數(shù)據(jù)庫。以前在單體應(yīng)用中很好解決的事務(wù)問題,現(xiàn)在變得很困難。在基于微服務(wù)的應(yīng)用程序中,需要更新不同服務(wù)所用的數(shù)據(jù)庫,通常不會(huì)選擇分布式事務(wù),不僅僅是因?yàn)?CAP 定理。他們根本不支持如今高度可擴(kuò)展的 NoSQL 數(shù)據(jù)庫和消息代理,最后不得不使用基于最終一致性的方法,這對(duì)于開發(fā)人員來說更具挑戰(zhàn)性。
3.測(cè)試微服務(wù)應(yīng)用程序也很復(fù)雜。例如,使用 Spring Boot,我只需要編寫一個(gè)測(cè)試類來啟動(dòng)一個(gè)單體 web 應(yīng)用程序并測(cè)試其 REST API。相比之下,一個(gè)類似的測(cè)試類對(duì)于微服務(wù)來說需要啟動(dòng)該服務(wù)及其所依賴的所有服務(wù),或者至少要做服務(wù)mock,雖然這不是一件高深的事情,但不要低估了這多出來的工作量和復(fù)雜度。
SOA與微服務(wù)的區(qū)別？
SOA的提出是在企業(yè)計(jì)算領(lǐng)域，就是要將緊耦合的系統(tǒng)，劃分為面向業(yè)務(wù)的，粗粒度，松耦合，無狀態(tài)的服務(wù)。服務(wù)發(fā)布出來供其他服務(wù)調(diào)用，一組互相依賴的服務(wù)就構(gòu)成了SOA架構(gòu)下的系統(tǒng)。
基于這些基礎(chǔ)的服務(wù)，可以將業(yè)務(wù)過程用類似BPEL流程的方式編排起來，而BPEL反映的是業(yè)務(wù)處理的過程，這些過程對(duì)于業(yè)務(wù)人員更為直觀，調(diào)整也比hardcode的代碼更容易。
當(dāng)然企業(yè)還需要對(duì)服務(wù)治理，比如服務(wù)注冊(cè)庫，監(jiān)控管理等。
我們知道企業(yè)計(jì)算領(lǐng)域，如果不是交易系統(tǒng)的話，并發(fā)量都不是很大的，所以大多數(shù)情況下，一臺(tái)服務(wù)器就容納將許許多多的服務(wù)，這些服務(wù)采用統(tǒng)一的基礎(chǔ)設(shè)施，可能都運(yùn)行在一個(gè)應(yīng)用服務(wù)器的進(jìn)程中。雖然說是面向服務(wù)了，但還是單一的系統(tǒng)。
而微服務(wù)架構(gòu)大體是從互聯(lián)網(wǎng)企業(yè)興起的，由于大規(guī)模用戶，對(duì)分布式系統(tǒng)的要求很高，如果像企業(yè)計(jì)算那樣的系統(tǒng)，伸縮就需要多個(gè)容納續(xù)續(xù)多多的服務(wù)的系統(tǒng)實(shí)例，前面通過負(fù)載均衡使得多個(gè)系統(tǒng)成為一個(gè)集群。但這是很不方便的，互聯(lián)網(wǎng)企業(yè)迭代的周期很短，一周可能發(fā)布一個(gè)版本，甚至可能每天一個(gè)版本，而不同的子系統(tǒng)的發(fā)布周期是不一樣的。而且，不同的子系統(tǒng)也不像原來企業(yè)計(jì)算那樣采用集中式的存儲(chǔ)，使用昂貴的Oracle存儲(chǔ)整個(gè)系統(tǒng)的數(shù)據(jù)，二是使用MongoDB，HBase，Cassandra等NOSQL數(shù)據(jù)庫和Redis，memcache等分布式緩存。那么就傾向采用以子系統(tǒng)為分割，不同的子系統(tǒng)采用自己的架構(gòu)，那么各個(gè)服務(wù)運(yùn)行自己的Web容器中，當(dāng)需要增加計(jì)算能力的時(shí)候，只需要增加這個(gè)子系統(tǒng)或服務(wù)的實(shí)例就好了，當(dāng)升級(jí)的時(shí)候，可以不影響別的子系統(tǒng)。這種組織方式大體上就被稱作微服務(wù)架構(gòu)。
微服務(wù)與SOA相比，更強(qiáng)調(diào)分布式系統(tǒng)的特性，比如橫向伸縮性，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，故障轉(zhuǎn)移，高可用。互聯(lián)網(wǎng)開發(fā)對(duì)服務(wù)治理提出了更多的要求，比如多版本，比如灰度升級(jí)，比如服務(wù)降級(jí)，比如分布式跟蹤，這些都是在SOA實(shí)踐中重視不夠的。
Docker容器技術(shù)的出現(xiàn)，為微服務(wù)提供了更便利的條件，比如更小的部署單元，每個(gè)服務(wù)可以通過類似Node.js或Spring Boot的技術(shù)跑在自己的進(jìn)程中。可能在幾十臺(tái)計(jì)算機(jī)中運(yùn)行成千上萬個(gè)Docker容器，每個(gè)容器都運(yùn)行著服務(wù)的一個(gè)實(shí)例。隨時(shí)可以增加某個(gè)服務(wù)的實(shí)例數(shù)，或者某個(gè)實(shí)例崩潰后，在其他的計(jì)算機(jī)上再創(chuàng)建該服務(wù)的新的實(shí)例。
如何拆分服務(wù)？
要圍繞業(yè)務(wù)模塊進(jìn)行拆分，拆分粒度應(yīng)該保證微服務(wù)具有業(yè)務(wù)的獨(dú)立性與完整性，盡可能少的存在服務(wù)依賴，鏈?zhǔn)秸{(diào)用。但是，在實(shí)際開發(fā)過程中，有的時(shí)候單體架構(gòu)更加適合當(dāng)前的項(xiàng)目。實(shí)際上，微服務(wù)的設(shè)計(jì)并不是一蹴而就的，它是一個(gè)設(shè)計(jì)與反饋過程。因此，我們?cè)谠O(shè)計(jì)之初可以將服務(wù)的粒度設(shè)計(jì)的大一些，并考慮其可擴(kuò)展性，隨著業(yè)務(wù)的發(fā)展，進(jìn)行動(dòng)態(tài)地拆分也是一個(gè)不錯(cuò)的選擇。
REST的名稱"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中，省略了主語。"表現(xiàn)層"其實(shí)指的是"資源"（Resources）的"表現(xiàn)層"。
所謂"資源"，就是網(wǎng)絡(luò)上的一個(gè)實(shí)體，或者說是網(wǎng)絡(luò)上的一個(gè)具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務(wù)，總之就是一個(gè)具體的實(shí)在。你可以用一個(gè)URI（統(tǒng)一資源定位符）指向它，每種資源對(duì)應(yīng)一個(gè)特定的URI。要獲取這個(gè)資源，訪問它的URI就可以，因此URI就成了每一個(gè)資源的地址或獨(dú)一無二的識(shí)別符。
客戶端用到的手段，只能是HTTP協(xié)議。具體來說，就是HTTP協(xié)議里面，四個(gè)表示操作方式的動(dòng)詞：GET、POST、PUT、DELETE。它們分別對(duì)應(yīng)四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。
實(shí)際上呢，不是所有的東西都是“資源”，尤其是在業(yè)務(wù)系統(tǒng)中，缺點(diǎn)如下：
有個(gè)接口是更新訂單狀態(tài)，你是用上面的GET POST PUT DELETE 哪個(gè)呢，看樣子應(yīng)該是PUT，但是路徑呢PUT /tickets/12
我有時(shí)候多個(gè)接口 ，更新訂單收款狀態(tài)，更新訂單支款狀態(tài)，更新訂單結(jié)算狀態(tài)；
Restful 的路徑明顯不友好不夠用；
再比如，批量刪除，DELETE還好用么，DELETE /tickets/12 #刪除ticekt 12 這種形式如果要傳數(shù)組怎么辦，url是不是不夠友好？
再比如，Resuful要求 GET /tickets # 獲取ticket列表 。我們?cè)?jīng)有個(gè)需求，對(duì)方會(huì)把不超過1000個(gè)訂單id傳給我們，我們系統(tǒng)過濾其中一部分特殊訂單；這也是個(gè)查詢服務(wù)，用GET /tickets # 獲取ticket列表的形式，1000個(gè)訂單id顯然是超過GET url長度的，這里也不合適；再者，我想開發(fā)多個(gè)條件查詢列表服務(wù)，路徑這么淺顯然不合適；
實(shí)際業(yè)務(wù)中，我們webapi的路徑是這樣的：systemAlias/controller/action
總結(jié)下規(guī)則：
簡單查詢盡量用GET，好處是可以直接帶查詢參數(shù)copy api路徑；
復(fù)雜查詢和更新用POST，用的最多；
不用PUT和DELETE，原因是增加復(fù)雜度，并沒有帶來什么好處
看看BAT的很多openapi，也是寫著restful，實(shí)際沒有嚴(yán)格遵守，都是get和post，這是也很多人不知道put和delete的原因
如：
//根據(jù)訂單id獲取訂單
GET oms/order/queryOrderById?id=value1param2=value2
//根據(jù)訂單id List獲取訂單
POST oms/order/queryOrderByIdList
//根據(jù)條件查詢訂單，帶分頁參數(shù)
POST oms/order/queryOrderByCondition
//更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatus
//批量更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatusInBatch
//批量刪除訂單，帶操作來源
POST oms/order/deleteOrderInBatch
微服務(wù)如何進(jìn)行數(shù)據(jù)庫管理？
CAP 原理(CAP Theorem)
在足球比賽里，一個(gè)球員在一場(chǎng)比賽中進(jìn)三個(gè)球，稱之為帽子戲法(Hat-trick)。在分布式數(shù)據(jù)系統(tǒng)中，也有一個(gè)帽子原理(CAP Theorem)，不過此帽子非彼帽子。CAP 原理中，有三個(gè)要素：
CAP 原理指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。
因此在進(jìn)行分布式架構(gòu)設(shè)計(jì)時(shí)，必須做出取舍。而對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求 ，否則就失去了價(jià)值，因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個(gè)平衡。
對(duì)于大多數(shù) WEB 應(yīng)用，其實(shí)并不需要強(qiáng)一致性，因此犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。
當(dāng)然，犧牲一致性，并不是完全不管數(shù)據(jù)的一致性，否則數(shù)據(jù)是混亂的，那么系統(tǒng)可用性再高分布式再好也沒有了價(jià)值。
犧牲一致性，只是不再要求關(guān)系型數(shù) 據(jù)庫中的強(qiáng)一致性，而是只要系統(tǒng)能達(dá)到最終一致性即可，考慮到客戶體驗(yàn)，這個(gè)最終一致的時(shí)間窗口，要盡可能的對(duì)用戶透明，也就是需要保障“用戶感知到的一致性”。
通常是通過數(shù)據(jù)的多份異步復(fù)制來實(shí)現(xiàn)系統(tǒng)的高可用和數(shù)據(jù)的最終一致性的，“用戶感知到的一致性”的時(shí)間窗口則 取決于數(shù)據(jù)復(fù)制到一致狀態(tài)的時(shí)間。
最終一致性(eventually consistent)
對(duì)于一致性，可以分為從客戶端和服務(wù)端兩個(gè)不同的視角。
從客戶端來看，一致性主要指的是多并發(fā)訪問時(shí)更新過的數(shù)據(jù)如何獲取的問題。
從服務(wù)端來看，則是更新如何復(fù)制分布到整個(gè)系統(tǒng)，以保證數(shù)據(jù)最終一致。
一致性是因?yàn)橛胁l(fā)讀寫才有的問題，因此在理解一致性的問題時(shí)，一定要注意結(jié)合考慮并發(fā)讀寫的場(chǎng)景。
從客戶端角度，多進(jìn)程并發(fā)訪問時(shí)，更新過的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。
對(duì)于關(guān)系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的 訪問都能看到，這是強(qiáng)一致性 ;如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性 ; 如果經(jīng)過一段時(shí)間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性。
從服務(wù)端角度，如何盡快將更新后的數(shù)據(jù)分布到整個(gè)系統(tǒng)，降低達(dá)到最終一致性的時(shí)間窗口，是提高系統(tǒng)的可用度和用戶體驗(yàn)非常重要的方面。
那么問題來了，如何實(shí)現(xiàn)數(shù)據(jù)的最終一致性呢?答案就在事件驅(qū)動(dòng)架構(gòu)。
最佳解決辦法是采用事件驅(qū)動(dòng)架構(gòu)。其中碰到的一個(gè)挑戰(zhàn)是如何原子性的更新狀態(tài)和發(fā)布事件。有幾種方法可以解決此問題，包括將數(shù)據(jù)庫視為消息隊(duì)列和事件源等。
從目前技術(shù)應(yīng)用范圍和成熟度看，推薦使用第一種方式(本地事務(wù)發(fā)布事件)，來實(shí)現(xiàn)事件投遞原子化，即可靠事件投遞。
SpringCloud和Dubbo有哪些區(qū)別？
總體來說，兩者各有優(yōu)勢(shì)。雖說后者服務(wù)調(diào)用的功能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級(jí)別的依賴，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下，顯得更加合適。
品牌機(jī)與組裝機(jī)的區(qū)別：很明顯SpringCloud比dubbo的功能更強(qiáng)大，覆蓋面更廣，而且能夠與SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring項(xiàng)目完美融合，這些對(duì)于微服務(wù)至關(guān)重要。使用Dubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦、各環(huán)節(jié)我們選擇自由度高，但是最總可能會(huì)因?yàn)閮?nèi)存質(zhì)量而影響整體，但對(duì)于高手這也就不是問題。而SpringCloud就像品牌機(jī)，在Spring Source的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性。
在面臨微服務(wù)基礎(chǔ)框架選型時(shí)Dubbo與SpringCloud只能二選一。
優(yōu)點(diǎn)：易于開發(fā)和維護(hù):一項(xiàng)服務(wù)只關(guān)注一項(xiàng)特定的業(yè)務(wù)功能，業(yè)務(wù)清晰，代碼量少。
微型服務(wù)的優(yōu)點(diǎn):
1.易于開發(fā)和維護(hù):一項(xiàng)服務(wù)只關(guān)注一項(xiàng)特定的業(yè)務(wù)功能，業(yè)務(wù)清晰，代碼量少。開發(fā)維護(hù)單項(xiàng)微服務(wù)相當(dāng)簡單。整個(gè)應(yīng)用程序由一些微型服務(wù)構(gòu)建，因此整個(gè)應(yīng)用程序處于可控狀態(tài)。
2.單一服務(wù)啟動(dòng)快:單一服務(wù)代碼少，啟動(dòng)快。
3.局部修改易于部署:單個(gè)應(yīng)用程序只要有修改，就必須重新部署整個(gè)應(yīng)用程序，微服務(wù)解決了這個(gè)問題。一般來說，修改某個(gè)微型服務(wù)，只需重新配置該服務(wù)。
4.技術(shù)堆棧不受限制:微服務(wù)結(jié)構(gòu)可結(jié)合業(yè)務(wù)和團(tuán)隊(duì)特點(diǎn)，合理選擇技術(shù)堆棧。例如，一些服務(wù)可以使用關(guān)系數(shù)據(jù)庫Mysql，一些服務(wù)可以使用非關(guān)系數(shù)據(jù)庫redis。甚至可以根據(jù)需服務(wù)可以使用JAVA開發(fā)，一些微服務(wù)可以使用Node.js開發(fā)。
5.按需收縮:可根據(jù)需要實(shí)現(xiàn)細(xì)粒度的擴(kuò)展。例如，系統(tǒng)中的某個(gè)微服務(wù)遇到瓶頸，可以結(jié)合微服務(wù)的特點(diǎn)，增加內(nèi)存，升級(jí)CPU，增加節(jié)點(diǎn)。
微型服務(wù)的缺點(diǎn):
1.運(yùn)輸要求高:更多的服務(wù)意味著更多的運(yùn)輸投入。在單體結(jié)構(gòu)中，只需保證一個(gè)應(yīng)用程序的運(yùn)行，在微服務(wù)中，需要保證幾十到幾百個(gè)服務(wù)器的正常運(yùn)行和合作，這給運(yùn)行維護(hù)帶來了巨大的挑戰(zhàn)
2.分戶式固有的復(fù)雜性:使用微服務(wù)結(jié)構(gòu)的是分布式系統(tǒng)。對(duì)于分布式系統(tǒng)，系統(tǒng)容錯(cuò)，網(wǎng)絡(luò)延遲帶來巨大挑戰(zhàn)。
3.界面調(diào)整成本高:微服務(wù)之間通過界面通信。
什么是微服務(wù)？
微服務(wù)(Microservices Architecture)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
微服務(wù)的概念源于2014年3月Martin Fowler所寫的文章“Microservices” martinfowler.com/articles/mi…
單體架構(gòu)(Monolithic Architecture )
企業(yè)級(jí)的應(yīng)用一般都會(huì)面臨各種各樣的業(yè)務(wù)需求，而常見的方式是把大量功能堆積到同一個(gè)單體架構(gòu)中去。比如：常見的ERP、CRM等系統(tǒng)都以單體架構(gòu)的方式運(yùn)行，同時(shí)由于提供了大量的業(yè)務(wù)功能，隨著功能的升級(jí)，整個(gè)研發(fā)、發(fā)布、定位問題，擴(kuò)展，升級(jí)這樣一個(gè)“怪物”系統(tǒng)會(huì)變得越來越困難。
這種架構(gòu)模式就是把應(yīng)用整體打包部署，具體的樣式依賴本身應(yīng)用采用的語言，如果采用java語言，自然你會(huì)打包成war包，部署在Tomcat或者Jetty這樣的應(yīng)用服務(wù)器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應(yīng)用以目錄層次的形式打包
上圖：單體架構(gòu)
大部分企業(yè)通過SOA來解決上述問題，SOA的思路是把應(yīng)用中相近的功能聚合到一起，以服務(wù)的形式提供出去。因此基于SOA架構(gòu)的應(yīng)用可以理解為一批服務(wù)的組合。SOA帶來的問題是，引入了大量的服務(wù)、消息格式定義和規(guī)范。
多數(shù)情況下，SOA的服務(wù)直接相互獨(dú)立，但是部署在同一個(gè)運(yùn)行環(huán)境中（類似于一個(gè)Tomcat實(shí)例下，運(yùn)行了很多web應(yīng)用）。和單體架構(gòu)類似，隨著業(yè)務(wù)功能的增多SOA的服務(wù)會(huì)變得越來越復(fù)雜，本質(zhì)上看沒有因?yàn)槭褂肧OA而變的更好。圖1，是一個(gè)包含多種服務(wù)的在線零售網(wǎng)站，所有的服務(wù)部署在一個(gè)運(yùn)行環(huán)境中，是一個(gè)典型的單體架構(gòu)。
單體架構(gòu)的應(yīng)用一般有以下特點(diǎn)：
微服務(wù)架構(gòu)（Microservices Architecture）
微服務(wù)架構(gòu)的核心思想是，一個(gè)應(yīng)用是由多個(gè)小的、相互獨(dú)立的、微服務(wù)組成，這些服務(wù)運(yùn)行在自己的進(jìn)程中，開發(fā)和發(fā)布都沒有依賴。不同服務(wù)通過一些輕量級(jí)交互機(jī)制來通信，例如 RPC、HTTP 等，服務(wù)可獨(dú)立擴(kuò)展伸縮，每個(gè)服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實(shí)現(xiàn)，由獨(dú)立的團(tuán)隊(duì)來維護(hù)。簡單的來說，一個(gè)系統(tǒng)的不同模塊轉(zhuǎn)變成不同的服務(wù)！而且服務(wù)可以使用不同的技術(shù)加以實(shí)現(xiàn)！
上圖：微服務(wù)架構(gòu)
微服務(wù)設(shè)計(jì)
那我們?cè)谖⒎?wù)中應(yīng)該怎樣設(shè)計(jì)呢。以下是微服務(wù)的設(shè)計(jì)指南：
微服務(wù)消息
在單體架構(gòu)中，不同功能之間通信通過方法調(diào)用，或者跨語言通信。SOA降低了這種語言直接的耦合度，采用基于SOAP協(xié)議的web服務(wù)。這種web服務(wù)的功能和消息體定義都十分復(fù)雜，微服務(wù)需要更輕量的機(jī)制。
同步消息 REST
同步消息就是客戶端需要保持等待，直到服務(wù)器返回應(yīng)答。REST是微服務(wù)中默認(rèn)的同步消息方式，它提供了基于HTTP協(xié)議和資源API風(fēng)格的簡單消息格式，多數(shù)微服務(wù)都采用這種方式（每個(gè)功能代表了一個(gè)資源和對(duì)應(yīng)的操作）
異步消息 – AMQP, STOMP, MQTT
異步消息就是客戶端不需要一直等待服務(wù)應(yīng)答，有應(yīng)到后會(huì)得到通知。某些微服務(wù)需要用到異步消息，一般采用AMQP, STOMP, MQTT 這三種通訊協(xié)議
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服務(wù)中另外一個(gè)很重要的因素。SOA的web服務(wù)一般采用文本消息，基于復(fù)雜的消息格式（SOAP）和消息定義（xsd）。微服務(wù)采用簡單的文本協(xié)議JSON和XML，基于HTTP的資源API風(fēng)格。如果需要二進(jìn)制，通過用到Thrift, ProtoBuf, Avro。
服務(wù)約定 – 定義接口 – Swagger, RAML, Thrift IDL
如果把功能實(shí)現(xiàn)為服務(wù)，并發(fā)布，需要定義一套約定。單體架構(gòu)中，SOA采用WSDL，WSDL過于復(fù)雜并且和SOAP緊耦合，不適合微服務(wù)。
REST設(shè)計(jì)的微服務(wù)，通常采用Swagger和RAML定義約定。
對(duì)于不是基于REST設(shè)計(jì)的微服務(wù)，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服務(wù)集成 (服務(wù)間通信)
大部分微服務(wù)基于RPC、HTTP、JSON這樣的標(biāo)準(zhǔn)協(xié)議，集成不同標(biāo)準(zhǔn)和格式變的不再重要。另外一個(gè)選擇是采用輕量級(jí)的消息總線或者網(wǎng)關(guān)，有路由功能，沒有復(fù)雜的業(yè)務(wù)邏輯。下面就介紹幾種常見的架構(gòu)方式。
點(diǎn)對(duì)點(diǎn)方式
點(diǎn)對(duì)點(diǎn)方式中，服務(wù)之間直接用。每個(gè)微服務(wù)都開放REST API，并且調(diào)用其它微服務(wù)的接口。
上圖：通過點(diǎn)對(duì)點(diǎn)方式通信
很明顯，在比較簡單的微服務(wù)應(yīng)用場(chǎng)景下，這種方式還可行，隨著應(yīng)用復(fù)雜度的提升，會(huì)變得越來越不可維護(hù)。這點(diǎn)有些類似SOA的ESB，盡量不采用點(diǎn)對(duì)點(diǎn)的集成方式。
API-網(wǎng)關(guān)方式
API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能個(gè)。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問API。服務(wù)端通過API-GW注冊(cè)和管理服務(wù)。
上圖：通過API-網(wǎng)關(guān)暴露微服務(wù)
所有的業(yè)務(wù)接口通過API網(wǎng)關(guān)暴露，是所有客戶端接口的唯一入口。微服務(wù)之間的通信也通過API網(wǎng)關(guān)。\
采用網(wǎng)關(guān)方式有如下優(yōu)勢(shì)：
目前，API網(wǎng)關(guān)方式應(yīng)該是微服務(wù)架構(gòu)中應(yīng)用最廣泛的設(shè)計(jì)模式。
消息代理方式
微服務(wù)也可以集成在異步的場(chǎng)景下，通過隊(duì)列和訂閱主題，實(shí)現(xiàn)消息的發(fā)布和訂閱。一個(gè)微服務(wù)可以是消息的發(fā)布者，把消息通過異步的方式發(fā)送到隊(duì)列或者訂閱主題下。作為消費(fèi)者的微服務(wù)可以從隊(duì)列或者主題共獲取消息。通過消息中間件把服務(wù)之間的直接調(diào)用解耦。
上圖：異步通信方式
通常異步的生產(chǎn)者/消費(fèi)者模式，通過AMQP, STOMP, MQTT 等異步消息通訊協(xié)議規(guī)范。
數(shù)據(jù)的去中心化
單體架構(gòu)中，不同功能的服務(wù)模塊都把數(shù)據(jù)存儲(chǔ)在某個(gè)中心數(shù)據(jù)庫中。
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。單體架構(gòu)，用一個(gè)數(shù)據(jù)庫存儲(chǔ)所有數(shù)據(jù)
微服務(wù)方式，多個(gè)服務(wù)之間的設(shè)計(jì)相互獨(dú)立，數(shù)據(jù)也應(yīng)該相互獨(dú)立（比如，某個(gè)微服務(wù)的數(shù)據(jù)庫結(jié)構(gòu)定義方式改變，可能會(huì)中斷其它服務(wù)）。因此，每個(gè)微服務(wù)都應(yīng)該有自己的數(shù)據(jù)庫。
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫，其它微服務(wù)不能直接訪問。
數(shù)據(jù)去中心話的核心要點(diǎn)：
數(shù)據(jù)的去中心化，進(jìn)一步降低了微服務(wù)之間的耦合度，不同服務(wù)可以采用不同的數(shù)據(jù)庫技術(shù)（SQL、NoSQL等）。在復(fù)雜的業(yè)務(wù)場(chǎng)景下，如果包含多個(gè)微服務(wù)，通常在客戶端或者中間層（網(wǎng)關(guān)）處理。
微服務(wù)架構(gòu)的優(yōu)點(diǎn)：
微服務(wù)架構(gòu)的缺點(diǎn)：
微服務(wù)的一些想法在實(shí)踐上是好的，但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性。
關(guān)于微服務(wù)架構(gòu)的取舍
微服務(wù)架構(gòu)是一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)。
大部分圍繞微服務(wù)的爭(zhēng)論都集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù)，而紅帽說API應(yīng)該是重點(diǎn)。
微服務(wù)架構(gòu)相關(guān)介紹：
微服務(wù)可以在“自己的程序”中運(yùn)行，并通過“輕量級(jí)設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運(yùn)行。通過這一點(diǎn)我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個(gè)API）區(qū)分開來。
在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨(dú)立進(jìn)程所限制。如果其中任何一個(gè)服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程的架構(gòu)。
微服務(wù)不需要像普通服務(wù)那樣成為一種獨(dú)立的功能或者獨(dú)立的資源。定義中稱，微服務(wù)是需要與業(yè)務(wù)能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設(shè)計(jì)是錯(cuò)誤的，那么，我們就必須付出很多代價(jià)。
如果你閱讀了Fowler的整篇文章，你會(huì)發(fā)現(xiàn)，其中的指導(dǎo)建議是非常實(shí)用的。在決定將所有組件組合到一起時(shí)，開發(fā)人員需要非常確信這些組件都會(huì)有所改變，并且規(guī)模也會(huì)發(fā)生變化。服務(wù)粒度越粗，就越難以符合規(guī)定原則。
服務(wù)粒度越細(xì)，就越能夠靈活地降低變化和負(fù)載所帶來的影響。然而，利弊之間的權(quán)衡過程是非常復(fù)雜的，我們要在配置和資金模型的基礎(chǔ)上考慮到基礎(chǔ)設(shè)施的成本問題。
重慶分公司
重慶分公司
