本文是來(lái)自于Macro在一次大會(huì)上的一個(gè)分享。
本系列共有兩個(gè)部分，主要關(guān)注我們?nèi)绾我约盀槭裁匆谖覀兊奈⒎?wù)應(yīng)用中部署API 網(wǎng)關(guān)。第二部分主要關(guān)注我們?nèi)绾伟?/span>Mashape的開(kāi)源網(wǎng)關(guān)組件Kong運(yùn)用到我們自己的微服務(wù)架構(gòu)當(dāng)中。
目錄
0:00 微服務(wù)與網(wǎng)關(guān)（Microservices & API Gateways）
大家好，我叫Macro，今天我們談?wù)撚嘘P(guān)微服務(wù)和網(wǎng)關(guān)的話題。我是Mashape的CTO,也同時(shí)是開(kāi)源網(wǎng)關(guān)Kong的開(kāi)發(fā)者之一。Kong是一個(gè)API網(wǎng)關(guān)，今天我們就來(lái)窺探一下它究竟是怎么工作的以及它如何運(yùn)用到你的微服務(wù)架構(gòu)中去。
0:23 主題（Topics）
為了明白我們?yōu)槭裁葱枰狝PI網(wǎng)關(guān)，我將從單體架構(gòu)vs微服務(wù)架構(gòu)談起。這兩個(gè)有什么不同點(diǎn)呢？然后我會(huì)介紹API網(wǎng)關(guān)模式以及它是如何適應(yīng)“面向微服務(wù)”的架構(gòu)的。然后我們會(huì)討論Kong以及NGINX。
0:47 單體架構(gòu)（Monolithic Architecture）
Ok，過(guò)去幾年我們目睹的一件事就是從單體應(yīng)用到面向微服務(wù)的架構(gòu)的過(guò)渡。我們都熟悉單體應(yīng)用程序，以及它們通常的工作原理，這是一個(gè)簡(jiǎn)單的展示。我們把所有的東西都放到一塊。而且通常也只有一個(gè)數(shù)據(jù)存儲(chǔ)。
通過(guò)在多個(gè)服務(wù)器上重復(fù)部署相同的巨大代碼塊，可以橫向擴(kuò)展單體應(yīng)用程序。所以每次我們調(diào)整應(yīng)用程序時(shí)，我們其實(shí)相當(dāng)于是在改動(dòng)這些被放在一起的所有的模塊，因?yàn)樗麄兪且惑w的。
1:45 單體應(yīng)用的優(yōu)缺點(diǎn)（Monolithic Application Pros and Cons）
每一種做法，都有利弊。單體應(yīng)用程序可以比較容易地構(gòu)建，而且是以更小的代碼庫(kù)來(lái)開(kāi)始。我們可以在同一個(gè)代碼庫(kù)中構(gòu)建和開(kāi)發(fā)所有內(nèi)容，這意味著我們不用擔(dān)心模塊化以及如何把不同的組件放在一起來(lái)共同工作這些事情。
而且測(cè)試起來(lái)也簡(jiǎn)單。通常當(dāng)我們測(cè)試一個(gè)單體應(yīng)用時(shí)，我們一開(kāi)始就只面對(duì)一個(gè)應(yīng)用，然后測(cè)試我們集成的單元測(cè)試。我們只需要面對(duì)一個(gè)應(yīng)用就夠了。
而且，很多IDE對(duì)單體應(yīng)用已經(jīng)支持的非常好了。比如Eclipse圍繞著單體應(yīng)用就提供了很多成熟的測(cè)試工具，包括idea也是。
但，你也許也發(fā)現(xiàn)了一個(gè)代碼庫(kù)(codebase)的問(wèn)題，隨著代碼量的急劇膨脹，我們把所有的都放在一個(gè)代碼庫(kù)里顯然不是一種理想的選擇。隨著時(shí)間的推移，越來(lái)越多的功能需要構(gòu)建進(jìn)去，代碼越來(lái)越多，在一個(gè)地方跟蹤代碼將變得更加的困難。
由于這些原因，團(tuán)隊(duì)在一個(gè)大的代碼庫(kù)上迭代將會(huì)變慢。再來(lái)說(shuō)個(gè)事情，比如我現(xiàn)在要更換數(shù)據(jù)庫(kù)存儲(chǔ)方案，或者想要使用一種新的技術(shù)。在單體應(yīng)用中，這樣的改動(dòng)通常是非常痛苦的。
由于上面所有的原因，你開(kāi)始擴(kuò)張你的組織。然后發(fā)生的事情就是團(tuán)隊(duì)內(nèi)部溝通成本變得更昂貴，因?yàn)槔斫獯a庫(kù)里的代碼究竟是干什么的變得更加困難。
3:55 微服務(wù)架構(gòu)（Microservice-Oriented Architecture）
在過(guò)去的幾年里（一兩年吧），我們親眼目睹了我們的應(yīng)用架構(gòu)向微服務(wù)轉(zhuǎn)變的這個(gè)過(guò)程。容器在這個(gè)轉(zhuǎn)變中也出了很大的力氣，因?yàn)樗鼑@微服務(wù)創(chuàng)建了一些偉大的工具，這一部分我們稍后會(huì)具體談到。
在一個(gè)微服務(wù)架構(gòu)中，你把應(yīng)用拆分成不同的模塊（component）。于是取而代之的是多個(gè)不同的service被彼此獨(dú)立的部署，彼此獨(dú)立的伸縮。在上面的這個(gè)例子中，客戶的訂單和發(fā)票，這些模塊將會(huì)被分別部署在他們自己的server上。
這些service之間的通信機(jī)制可以是多種格式的，通常是HTTP 或者 RPC（以及事件發(fā)布訂閱的方式）。有時(shí)候你也可為每個(gè)模塊分配不同的數(shù)據(jù)存儲(chǔ)schema。這樣的話，我們就把每個(gè)模塊的能力都隔離開(kāi)了，而且你還讓它獨(dú)立于其他模塊而工作。
這樣也意味著很多時(shí)候你可能需要通過(guò)事件源機(jī)制來(lái)搞定一些事件觸發(fā)。在這個(gè)例子中，客戶端創(chuàng)建一個(gè)新的訂單。你就可以不用讓客戶端創(chuàng)建訂單并且生成發(fā)票，取而代之的是，你可以創(chuàng)建一個(gè)新的訂單，然后Orders這個(gè)模塊push一個(gè)生成發(fā)票事件，然后其他的模塊可以監(jiān)聽(tīng)這個(gè)事件，然后來(lái)異步生成發(fā)票。
這樣的話，你算是構(gòu)建了一個(gè)異步的應(yīng)用程序，它沒(méi)有依賴于客戶端并且它可以自主的為你生成發(fā)票。這也就是意味著，如果Invoices模塊down了，可以在稍后重試生成發(fā)票。
5:47 微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)（Microservice-Oriented Application Pros and Cons）
面向微服務(wù)的架構(gòu)也有其兩面性。微服務(wù)并不適合所有的主體，也不能hold所有的使用場(chǎng)景。它適合大型應(yīng)用。如果您有大型應(yīng)用程序，則可以將此大型應(yīng)用程序拆分成不同的模塊，開(kāi)發(fā)人員將能夠獨(dú)立地迭代，維護(hù)和構(gòu)建這些模塊。
微服務(wù)的每個(gè)模塊（component）只做一件事情，有且僅有一件事情可以做，你可以輕松基于此迭代并且盡情的完善和創(chuàng)新該模塊，而且還不會(huì)影響到其他的模塊。每個(gè)模塊之間，彼此通過(guò)接口進(jìn)行通信（大多數(shù)時(shí)候），比如HTTP RESTful接口。你可以改變和實(shí)驗(yàn)性的搞一些實(shí)現(xiàn)，只要接口不改變，應(yīng)用就會(huì)保持正常的運(yùn)轉(zhuǎn)。
微服務(wù)，Microservices是micro。意味著如果你需要scale組織或團(tuán)隊(duì)，你可以為你的團(tuán)隊(duì)成員分配一些更小的，應(yīng)用程序中的一些小碎片，更小的開(kāi)發(fā)任務(wù)。這對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，有助于他們更快的理解自己要做什么，代碼是如何運(yùn)作的。而且迭代起來(lái)也更快。如果他們要用到其他的模塊，他們可以使用接口去消費(fèi)（consume）其他的模塊，而不需要深入到其他模塊的代碼中去。
在單體應(yīng)用中，有的地方發(fā)生了錯(cuò)誤，意味著整個(gè)應(yīng)用程序就無(wú)法運(yùn)轉(zhuǎn)了。很多時(shí)候一個(gè)bug導(dǎo)致整個(gè)應(yīng)用程序就down了。而在微服務(wù)架構(gòu)中，如果出現(xiàn)一個(gè)問(wèn)題，這個(gè)問(wèn)題是被隔離在一個(gè)特定的模塊中或者是某個(gè)service中。
這意味著整個(gè)應(yīng)用程序只有那一個(gè)service處于停止?fàn)顟B(tài)，而其他的模塊則可以照常運(yùn)轉(zhuǎn)。就是說(shuō)我們現(xiàn)在有Orders和Invoices兩個(gè)模塊。如果由于一些原因，開(kāi)發(fā)人員在周五晚上push了一個(gè)bug到Invoices模塊上，然后導(dǎo)致了發(fā)票模塊不能工作。我們依然可以保存了這個(gè)發(fā)票事件。一旦Invoices模塊恢復(fù)了，我們就可以繼續(xù)生成發(fā)票了（那個(gè)之前由于bug而沒(méi)有被創(chuàng)建的發(fā)票又可以被創(chuàng)建了）。
這樣的功能我們?cè)趩误w應(yīng)用中也可以實(shí)現(xiàn)，但是由于微服務(wù)架構(gòu)的推動(dòng)，讓這種事件驅(qū)動(dòng)的風(fēng)格更加的發(fā)揚(yáng)光大，而隨著時(shí)間的推移，單體應(yīng)用變成了“意大利面應(yīng)用”（spaghetti apps）。
面向微服務(wù)應(yīng)用也有一些很典型的缺點(diǎn)。其中一個(gè)就是你現(xiàn)有有一堆不再“固定”的零部件?，F(xiàn)在不再是單體那樣一個(gè)app在一個(gè)地方做了所有事情?，F(xiàn)在你有多個(gè)模塊和（或）service。這些模塊要在同一時(shí)刻共同配合才能最終呈現(xiàn)給用戶。
這意味著你要有更強(qiáng)大的基礎(chǔ)設(shè)施能力?，F(xiàn)在你需要有一種魔法，要能簡(jiǎn)單地部署、伸縮、以及監(jiān)控和管理這些不同的模塊，這些獨(dú)立的模塊。這也是這些年來(lái)實(shí)時(shí)的在線監(jiān)控和分析技術(shù)變得如此火爆的原因之一吧。因?yàn)橐坏┠闶敲嫦蛭⒎?wù)的架構(gòu)，你就必須去監(jiān)控每一個(gè)碎片（零部件）并且要在一個(gè)集中的地方可以看到你的模塊們的運(yùn)行狀態(tài)。
在單體中，你只有一個(gè)代碼庫(kù)來(lái)保存，執(zhí)行并且所有的entity都在一塊。在微服務(wù)架構(gòu)中，我們有很多不同的模塊，他們都彼此獨(dú)立運(yùn)行，并且只干一件事情。
這就意味著你現(xiàn)在有一個(gè)可用性的問(wèn)題：service們也許會(huì)go down 不可用?；蛘哌€會(huì)有一致性問(wèn)題：也許你需要把這些微服務(wù)scale到多個(gè)數(shù)據(jù)中心。所以你在創(chuàng)建一個(gè)應(yīng)用時(shí)，就要把這些問(wèn)題都要考慮進(jìn)去。
如果你想要測(cè)試一個(gè)service，有的簡(jiǎn)單，有的比較難。這取決于你要測(cè)試的內(nèi)容。
如果只是測(cè)試一個(gè)獨(dú)立的模塊，那就比較簡(jiǎn)單。但要測(cè)試一個(gè)多重依賴的那種的話可能就比較復(fù)雜了。通常的話，如果你想要測(cè)試一個(gè)構(gòu)建于微服務(wù)架構(gòu)之上的應(yīng)用的話，前提條件就是你必須要同時(shí)啟動(dòng)所有的這些模塊，這樣可以確保彼此都可以相互通信，并且要成功地實(shí)現(xiàn)了集成測(cè)試。
11:18 為什么需要API網(wǎng)關(guān)？
Ok，為什么我們需要一個(gè)API網(wǎng)關(guān)呢？
我們總是聽(tīng)到編排這個(gè)詞，所以我喜歡這張幻燈片 – 它展示了一個(gè)樂(lè)隊(duì)，然后有個(gè)指揮家，下面一堆人（微型服務(wù)）演奏自己的樂(lè)器。這個(gè)指揮家（API網(wǎng)關(guān)）可以以某種方式來(lái)協(xié)調(diào)我們的架構(gòu)如何處理請(qǐng)求。
11:54 API網(wǎng)關(guān)模式（API Gateway Pattern）
API 網(wǎng)關(guān)模式意味著你要把API 網(wǎng)關(guān)放到你的微服務(wù)們的最前端，并且要讓API 網(wǎng)關(guān)變成由應(yīng)用所發(fā)起的每個(gè)請(qǐng)求的入口。這樣就可以明顯的簡(jiǎn)化客戶端實(shí)現(xiàn)和微服務(wù)應(yīng)用程序之間的溝通方式。
以前的話，客戶端不得不去請(qǐng)求Customers，然后再到Orders，然后是Invoices?？蛻舳诵枰ブ涝趺?/span>去一起來(lái)消費(fèi)這三個(gè)不同的service。使用API網(wǎng)關(guān)，我們可以抽象所有這些復(fù)雜性，并創(chuàng)建客戶端們可以使用的優(yōu)化后的端點(diǎn)，并向那些模塊們發(fā)出請(qǐng)求。
12:53 優(yōu)化后的端點(diǎn)（Optimized Endpoints）
例如，優(yōu)化的端點(diǎn)。如果我們假設(shè)客戶（Customers），訂單（Orders）和發(fā)票（Invoices）每個(gè)模塊都返回不同的JSON響應(yīng)，并且假設(shè)客戶端想要檢索此信息。有兩種方法。一種方式是，客戶端向客戶(Customers)模塊發(fā)出GET請(qǐng)求以檢索客戶，然后到訂單(Orders)，然后到指定訂單的發(fā)票（Invoices）。
第二種方式是我們可以通過(guò)使用API網(wǎng)關(guān)來(lái)抽象此客戶端實(shí)現(xiàn)的復(fù)雜性。然后，API網(wǎng)關(guān)可以公開(kāi)一個(gè)特定的端點(diǎn)，在這個(gè)端點(diǎn)上將產(chǎn)生請(qǐng)求，然后在[網(wǎng)關(guān)]消費(fèi)了微服務(wù)之后返回給客戶端一個(gè)唯一的響應(yīng)（response）。
也就是說(shuō)，比如，我們可以把很多的response折疊成一個(gè)，request也是一個(gè)。這樣對(duì)我們幫助很大，而且特別是對(duì)于手機(jī)等其他移動(dòng)客戶端來(lái)說(shuō)特別的受益。這樣就可以加速我們的客戶端的實(shí)現(xiàn)。而且可以輕松的做一些替換。
有一個(gè)很nice的事情，就是API網(wǎng)關(guān)讓我們的客戶端不用再需要知道和關(guān)心模塊的地址（address）了。網(wǎng)關(guān)負(fù)責(zé)來(lái)搞這些事情，你只需要知道網(wǎng)關(guān)就好了。你可以去改變實(shí)現(xiàn)而且還可以改變API接口。不過(guò)通常來(lái)說(shuō)，你改變接口后，會(huì)增加客戶端出問(wèn)題的風(fēng)險(xiǎn)。
使用API網(wǎng)關(guān)后，你可以在單獨(dú)的層上有效地抽象，這樣你就可以更改實(shí)現(xiàn)和接口，同時(shí)保持現(xiàn)有客戶端的公共接口相同。這意味著你總是可以做一些調(diào)整的事情。
API網(wǎng)關(guān)對(duì)于那些從單體轉(zhuǎn)變到微服務(wù)的應(yīng)用來(lái)說(shuō)也是一個(gè)非常有幫助的工具。如果你現(xiàn)在維護(hù)一個(gè)單體應(yīng)用，你就可以把一個(gè)API網(wǎng)關(guān)放到這個(gè)單體的最前面，然后你就慢慢地開(kāi)始把單體拆分成很多的不同的微服務(wù)，在這個(gè)過(guò)程中，客戶端就一直是通過(guò)API網(wǎng)關(guān)來(lái)保持自己的運(yùn)作，這樣讓你的遷移過(guò)程更優(yōu)雅！
API網(wǎng)關(guān)將隨著時(shí)間的推移實(shí)現(xiàn)和消費(fèi)后端的上游service，同時(shí)保持客戶端的正常工作。擁有一個(gè)API網(wǎng)關(guān)可以幫助我們實(shí)現(xiàn)這樣的過(guò)渡。
15:28 中心化中間件（Centralized Middleware Functionality）
當(dāng)然了，創(chuàng)建一個(gè)優(yōu)化的端點(diǎn)僅僅是API網(wǎng)關(guān)的好處之一。你還可以通過(guò)API網(wǎng)關(guān)中心化中間件的能力。當(dāng)你開(kāi)始創(chuàng)建越來(lái)越多的服務(wù)時(shí)，你會(huì)發(fā)現(xiàn)自己面臨了一個(gè)新的問(wèn)題 – 就是你發(fā)現(xiàn)你需要對(duì)一些服務(wù)進(jìn)行身份驗(yàn)證和流量控制。
有的服務(wù)是public的；有的是private的；有的則是合作伙伴的API，這些你只能提供給一些特定的用戶。遲早你會(huì)發(fā)現(xiàn)自己在實(shí)現(xiàn)每個(gè)微服務(wù)時(shí)總是一次次的重復(fù)編寫(xiě)一些相同的代碼，這些代碼其實(shí)都是可以抽象為中間件的。
這顯然不是每個(gè)微服務(wù)應(yīng)該去關(guān)注的事情。API網(wǎng)關(guān)才應(yīng)該把這件事情攬下，也就是說(shuō)微服務(wù)只負(fù)責(zé)接收進(jìn)來(lái)的request-然后返回一個(gè)類似JSON格式的response即可。然后API網(wǎng)關(guān)就把這些例如身份驗(yàn)證、日志（logging）以及流量控制都?xì)w于麾下。
在這個(gè)slide，還要介紹的就是最下面的Faas（function as a service），這個(gè)是一個(gè)很酷的東西。它意味著你正在消費(fèi)的某個(gè)API端點(diǎn)可能正在地球的某一個(gè)角落在做一些事情。
它也許運(yùn)行在一個(gè)serverless的架構(gòu)之上，或者并沒(méi)有運(yùn)行在你自己的server上。這意味著你同樣可以在這些能力前面前置一個(gè)API網(wǎng)關(guān)，也可以在他們之上運(yùn)行一些上面所說(shuō)的那些中間件。
17:24 Ops: Blue/Green Deployments
這里我只是向你們展示了一些使用場(chǎng)景，然后讓你知道它是如何讓我們的“生活”變得更簡(jiǎn)單。比如，布署，deploy這件事情。在微服務(wù)架構(gòu)中，一個(gè)特定的service也許在一天內(nèi)要被deploy很多次（它不像單體時(shí)布署是一件艱難的事情）。
在單體應(yīng)用中，布署（deployment）往往是一件比較耗時(shí)和緩慢的事情，因?yàn)槟忝看巫龅囊稽c(diǎn)點(diǎn)改變，你都不得不要把一整個(gè)單體應(yīng)用重新布署一遍。而且隨著應(yīng)用規(guī)模的增長(zhǎng)，布署這件事情就變得越來(lái)越復(fù)雜。而在微服務(wù)中呢？你可以獨(dú)立的去布署一個(gè)模塊很多次，因?yàn)槟K布署起來(lái)要更快更容易，因?yàn)橹恍枰际鹨粋€(gè)小小的塊。
而且如果你需要，你還可以實(shí)現(xiàn)blue/green布署，API網(wǎng)關(guān)可以讓這件事情通過(guò)一種簡(jiǎn)單的方式實(shí)現(xiàn)變?yōu)榭赡?。比如，如果有一些Customer模塊是1.0.0版本，有些Customer模塊則是1.0.1版本。網(wǎng)關(guān)能夠知道這些所有的版本的模塊的location，然后提供接口可以讓你從舊的版本切換到新的版本。
18:50 Ops:金絲雀發(fā)布（Canary Releases）
另一種發(fā)布策略是金絲雀發(fā)布（canaryreleases）。當(dāng)我們創(chuàng)建軟件的時(shí)候，有時(shí)候你不希望讓所有的流量都一次性的到達(dá)新的版本，因?yàn)槟莻€(gè)新的版本也許并沒(méi)有測(cè)試地很充分。
金絲雀發(fā)布策略允許你直接只導(dǎo)入指定量的流量到新的版本，API網(wǎng)關(guān)就可以幫你來(lái)做這件事情。你可以配置10%的請(qǐng)求到新的版本，然后一旦你確保了新版本沒(méi)有bug，你可以把流量切換到100%。
19:34 Ops:負(fù)載均衡（ Load Balancing）
API網(wǎng)關(guān)的另外的一個(gè)能力就是可以負(fù)載均衡。在一定場(chǎng)景下，API網(wǎng)關(guān)可以是負(fù)載均衡器。API網(wǎng)關(guān)知道所有的service的地址和位置，所以你可以在API網(wǎng)關(guān)和上游service之間加一個(gè)負(fù)載均衡器。或者它本身就是一個(gè)負(fù)載均衡器。
當(dāng)它是負(fù)載均衡器時(shí)，API網(wǎng)關(guān)就可以利用諸如Consul或etcd這些服務(wù)發(fā)現(xiàn)工具來(lái)負(fù)載均衡請(qǐng)求（request）。
每次你去請(qǐng)求一個(gè)DNS地址，服務(wù)發(fā)現(xiàn)（service?discovery）工具就會(huì)給你一個(gè)新的IP地址。一般會(huì)在DNS這一層中做一些類似round-robin等策略的負(fù)載均衡。
20:36 Ops: 斷路器（Circuit Breakers）
現(xiàn)在我們閉目想想，假定你的某個(gè)service突然停止了工作，然后返回了大量的錯(cuò)誤。
API網(wǎng)關(guān)可以幫你實(shí)現(xiàn)斷路器(circuit breakers)的能力,也就是說(shuō)超過(guò)了指定的閾值，API網(wǎng)關(guān)就會(huì)停止發(fā)送數(shù)據(jù)到那些失敗的模塊。
這樣就給了我們時(shí)間來(lái)分析日志，實(shí)現(xiàn)修復(fù)以及push更新。通常當(dāng)你發(fā)現(xiàn)一個(gè)模塊下的某個(gè)實(shí)例失敗后，這時(shí)候這個(gè)模塊依然還會(huì)接收流量，然后這個(gè)有問(wèn)題的模塊還調(diào)用了其他的模塊，這樣就會(huì)發(fā)生級(jí)聯(lián)故障，或者叫雪崩。
斷路器通過(guò)簡(jiǎn)單的斷開(kāi)流量的方式，這樣就不會(huì)有新的請(qǐng)求到達(dá)那些有問(wèn)題的實(shí)例，這時(shí)候我們就有相對(duì)充分的時(shí)間來(lái)修復(fù)和解決問(wèn)題。
21:35 構(gòu)建微服務(wù)vs運(yùn)行微服務(wù)（Building vs Running a Microservice）
在這里我想說(shuō)明一個(gè)經(jīng)常被誤解的內(nèi)容。有時(shí)，產(chǎn)品經(jīng)理和軟件工程師認(rèn)為，構(gòu)建API與運(yùn)行API相同，因此構(gòu)建微服務(wù)與運(yùn)行微服務(wù)相同，但這是兩個(gè)不同的問(wèn)題。他們必須以不同的方式解決。
22:01工作量分布（Division of Labor）
我認(rèn)為構(gòu)建API通常是構(gòu)建微服務(wù)器所需的工作量的50％。這是一個(gè)大概的估計(jì)，并不是把每個(gè)人都考慮到了?，F(xiàn)在我們有一個(gè)API運(yùn)行，它可以接受請(qǐng)求和返回響應(yīng)，但是我們?nèi)绾翁幚砉芾?，身份?yàn)證，流量控制和速率限制？
那么我們用戶的速率限制之后的下一步就是將這些用戶的一小部分列入白名單的問(wèn)題，允許這一部分人無(wú)論如何都不會(huì)被限制。這算是一種更高端的速率限制。
微服務(wù)可以為你提供更多，不僅僅是一個(gè)你可以消費(fèi)的API。
然后是監(jiān)控分析 - 這是非常重要的。你需要持續(xù)地監(jiān)視和跟蹤模塊和文檔的狀態(tài)。 如果你有API，你還需要有適當(dāng)?shù)奈臋n。這不僅對(duì)公共開(kāi)發(fā)人員而言是重要的，而且對(duì)于組織內(nèi)部的開(kāi)發(fā)人員也是重要的。
比如你有一個(gè)語(yǔ)音API以及一個(gè)SMS API，如果您希望紐約和舊金山的兩個(gè)團(tuán)隊(duì)合作，團(tuán)隊(duì)只需要發(fā)布一個(gè)API接口的文檔，然后你組織內(nèi)的任何人都可以使用那個(gè)API。保持文檔最新是非常重要的。
這也是通常在創(chuàng)建新API時(shí)一般不會(huì)納入那50％的一部分內(nèi)容，但這確實(shí)是面向微服務(wù)的體系架構(gòu)的一部分。
下集將會(huì)介紹Kong如何運(yùn)用到你的微服務(wù)架構(gòu)中。
聯(lián)系客服
