介紹

本文是介紹如何實(shí)現(xiàn)完全自動(dòng)化的持續(xù)部署系統(tǒng)的系列文章之一庇谆。想要了解整個(gè)系列內(nèi)容請(qǐng)參考這篇文章 。

在本文中凭疮，我希望介紹什么才是一個(gè)真正的微服務(wù)饭耳。我還會(huì)列舉一些用來決定是否應(yīng)該使用微服務(wù)的原因。最后执解，我會(huì)簡短概況一下使用基于微服務(wù)架構(gòu)所產(chǎn)生的影響寞肖。

什么是微服務(wù)（micro service）？

很多開發(fā)人員第一眼看到這個(gè)詞時(shí)衰腌，會(huì)被“微”這個(gè)字所誤導(dǎo)新蟆。我們不應(yīng)該按照字面意思來理解，頂多可以將微服務(wù)（簡稱MS）看做是一個(gè)比較小型的東西右蕊。

通常琼稻，微服務(wù)是一組邏輯上屬于一體的相關(guān)功能集合。如果你熟悉領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（domain driven design饶囚，縮寫為DDD） 帕翻，可以將一個(gè)微服務(wù)想象成一個(gè)邊界上下文（bound context）的實(shí)現(xiàn)。但這不是我們能夠用來定義微服務(wù)的唯一方式坯约。在現(xiàn)實(shí)中熊咽，你希望將一些功能封裝成微服務(wù)的理由可能還包括以下幾點(diǎn)：

• 變更的頻率：應(yīng)用程序的某些部分需要非常頻繁的進(jìn)行變更，而其他一些部分卻很穩(wěn)定闹丐，很少更改。
• 基礎(chǔ)設(shè)施：應(yīng)用程序的某些部分對(duì)底層運(yùn)行的基礎(chǔ)設(shè)施有特定要求被因，例如對(duì)內(nèi)存大小卿拴、磁盤I/O或者網(wǎng)路吞吐方面的要求衫仑。而應(yīng)用程序的其他部分沒有這種要求。
• 可伸縮性：應(yīng)用程序的某些部分需要極其靈活的可伸縮性堕花。
• 安全：應(yīng)用程序的某些部分需要進(jìn)行高度的安全保護(hù)文狱。
• 工具集：應(yīng)用程序的某些部分更適于用其他的語言實(shí)現(xiàn)，例如像F#或者Clojure這樣的函數(shù)式語言缘挽。
• 平臺(tái)：有些時(shí)候我們希望讓應(yīng)用程序的某些部分運(yùn)行在不同的平臺(tái)上瞄崇，例如Windows或者Linux。
• 等等壕曼。

微服務(wù)的特點(diǎn)

一旦我們確定了想要實(shí)現(xiàn)成微服務(wù)的功能苏研，那么就需要確認(rèn)我們的微服務(wù)是否具有以下幾個(gè)特點(diǎn)：

• 微服務(wù)對(duì)于外界就像一個(gè)黑盒一樣。它擁有定義良好的面向外部系統(tǒng)的接口腮郊。
• 微服務(wù)可以被其他具有相同功能的服務(wù)完全替代摹蘑。當(dāng)然，新的服務(wù)需要實(shí)現(xiàn)原有服務(wù)的接口定義轧飞。
• 對(duì)外部的接口應(yīng)當(dāng)是定義良好的衅鹿，并且應(yīng)當(dāng)盡可能少的發(fā)生變化。
• 對(duì)外部的接口應(yīng)當(dāng)是可以按照版本管理的过咬，以便讓微服務(wù)可以向后兼容其他原有的系統(tǒng)大渤。新的外部系統(tǒng)可以使用新版本的接口定義。
• 微服務(wù)應(yīng)當(dāng)擁有屬于自己的代碼倉庫掸绞，例如GitHub或者其他任何源代碼版本控制軟件兼犯。注意：某些人不同意這一點(diǎn)，但是至少微服務(wù)應(yīng)該在主倉庫中擁有自己的子倉庫集漾。
• 每個(gè)微服務(wù)都可單獨(dú)進(jìn)行部署切黔。每個(gè)微服務(wù)都與應(yīng)用程序的其他部分相互獨(dú)立，可以在任意時(shí)間進(jìn)行單獨(dú)部署具篇，而不用同時(shí)需要部署其他微服務(wù)的更新版本纬霞。

由于按照定義，微服務(wù)是一個(gè)小型的服務(wù)驱显，所以實(shí)現(xiàn)該微服務(wù)的代碼量也應(yīng)當(dāng)盡量的少诗芜。這樣，我們可以避免使用大型系統(tǒng)中的某些設(shè)計(jì)埃疫，來降低系統(tǒng)的復(fù)雜性伏恐。這些設(shè)計(jì)通常包括使用IoC框架或者像NHibernate或Entity Framework這樣的ORM框架。

微服務(wù)的接口

微服務(wù)需要提供功能給外部系統(tǒng)訪問栓霜。出于該原因翠桦，所有微服務(wù)都需要實(shí)現(xiàn)一組定義良好的接口。通常這些接口以RESTful API的形式提供，但是并不是僅此一種销凑。其他一些接口類型還包括消息隊(duì)列丛晌、tcp/ip或者udp實(shí)現(xiàn)的等等。由于一般應(yīng)用系統(tǒng)的大多數(shù)微服務(wù)不會(huì)被公開暴露斗幼，所以我們可以選擇最合適的協(xié)議或技術(shù)來實(shí)現(xiàn)澎蛛，這樣就不會(huì)讓自己僅僅局限于RESTful API。更重要的是蜕窿，微服務(wù)的接口應(yīng)該永遠(yuǎn)保持穩(wěn)定谋逻，并且是可按照版本管理的。

微服務(wù)示例

為了避免光談一些微服務(wù)的抽象概念桐经，我們舉幾個(gè)現(xiàn)實(shí)中適合于做成微服務(wù)的幾個(gè)例子：

• 產(chǎn)品分類：該服務(wù)提供維護(hù)商店庫存的一些功能毁兆、包括添加、修改次询、下架商品等荧恍。
• 快遞：一旦顧客將訂單發(fā)給這個(gè)服務(wù)，就由它來負(fù)責(zé)將商品快遞到客戶手中屯吊。
• 文檔生成：為了符合規(guī)定送巡，需要在業(yè)務(wù)交易中生成或向客戶呈現(xiàn)某些條款和法律文件。以一個(gè)常見的文檔舉例盒卸，當(dāng)用戶的信用報(bào)告存在“hard inquiry”時(shí)骗爆，需要向客戶發(fā)送一個(gè)不良行為通知（美國查詢信用報(bào)告有兩種方式，“hard inquiry”或“hard pull”會(huì)對(duì)信用記錄有負(fù)面影響蔽介，而“soft inquiry”或“soft pull”不會(huì)有影響）摘投。這個(gè)服務(wù)可以通過在模板上填寫動(dòng)態(tài)數(shù)據(jù)的方式來生成文檔。
• 郵件服務(wù)：該服務(wù)負(fù)責(zé)使用郵件合并這樣的技術(shù)虹蓄，基于模板來生成郵件犀呼，并通過SMTP服務(wù)器將郵件發(fā)送給收件人。郵件可以基于事件觸發(fā)薇组，或者按照預(yù)定好的時(shí)間點(diǎn)來發(fā)送外臂。

作者介紹

Gabriel N. Schenker最早的職業(yè)是一名物理學(xué)家。遵循內(nèi)心對(duì)星球和宇宙的渴望和愛好律胀，他選擇了天體物理學(xué)作為博士研究方向宋光。博士畢業(yè)之后，他很快將全部的精力都投入到了第二愛好——編寫和設(shè)計(jì)軟件架構(gòu)炭菌。Gabriel已經(jīng)工作了超過20年罪佳，主要從事.NET平臺(tái)方面的顧問、軟件架構(gòu)師黑低、培訓(xùn)師等工作赘艳。他現(xiàn)在是德克薩斯州奧斯汀ClearMeasure公司的首席軟件架構(gòu)師。Gabriel熱衷于軟件開發(fā)，并且希望能夠通過提供一些開發(fā)原則和框架來提高開發(fā)效率第练。如今Gabriel已經(jīng)成家并且是四個(gè)孩子的父親阔馋，在工作之余他喜歡在山脈間徒步旅行玛荞、做飯和閱讀娇掏。

原文發(fā)表于這里

歡迎打賞（微信請(qǐng)點(diǎn)擊“閱讀原文”），也請(qǐng)關(guān)注微信公眾賬號(hào)“重度恐高癥”勋眯，精彩技術(shù)文章就在這里婴梧。