前言：

今年在新公司接觸到了微服務(wù)和RPC的概念。我想從我著手的項(xiàng)目，再到公司的技術(shù)架構(gòu)談一談我對(duì)微服務(wù)的理解。

我所認(rèn)識(shí)的微服務(wù)

微服務(wù)模型

下面我詳細(xì)的介紹下這里的過(guò)程。

1. 制造thrift dataobject。
   當(dāng)需要一個(gè)對(duì)數(shù)據(jù)操作的業(yè)務(wù)時(shí)。我們要編寫(xiě)一個(gè)對(duì)外的thrift接口。
   首先需要思考這個(gè)接口需要傳遞哪些參數(shù)，返回哪些參數(shù)，這些參數(shù)分別是什么數(shù)據(jù)類(lèi)型（這和很多強(qiáng)類(lèi)型的語(yǔ)言的感覺(jué)很類(lèi)似）想清楚之后，就可以構(gòu)建入?yún)⒑统鰠⒌臄?shù)據(jù)類(lèi)型。當(dāng)然thrift本身提供了一些比較簡(jiǎn)單的數(shù)據(jù)類(lèi)型，如整形，字符型等等。在這些基礎(chǔ)數(shù)據(jù)類(lèi)型之上。構(gòu)建出自己需要的入?yún)⒒虺鰠⒌臄?shù)據(jù)類(lèi)型。我稱(chēng)之為編寫(xiě)數(shù)據(jù)對(duì)象

下面舉個(gè)例子

#入?yún)?duì)象
struct loginInput{
    1:string username;#賬號(hào)名
    2:string password;#密碼
}
#返回的用戶對(duì)象
struct userobj{
    1:i32 uid,#用戶ID
    2:string name,#用戶名
    3:string userface,#頭像
}

2. 制造thrift interface
   我們知道，php，java都是有interface抽象接口概念的。接口中會(huì)有抽象方法，這些方法規(guī)定了方法名或者更多參數(shù)。集成類(lèi)中需要實(shí)現(xiàn)這些抽象方法。這里制造interface就是這個(gè)概念
   下面是例子

service UserService{
    #通過(guò)賬號(hào)密碼獲取用戶信息
    user.userobj GetUserInfo(1:user.loginInput);
}

這里構(gòu)造GetUserInfo這個(gè)抽象方法，我們規(guī)定了他的入?yún)⒑统鰠⒌臄?shù)據(jù)類(lèi)型。類(lèi)型就是上我們定義的兩個(gè)數(shù)據(jù)對(duì)象。只有按照這個(gè)規(guī)定的參數(shù)傳遞才不會(huì)報(bào)錯(cuò)

3. 打包生成sdk
   這里就不做演示了。總之神奇的地方就是這里。這里會(huì)有一個(gè)shell文件的方式來(lái)對(duì)我們之前定義的東西進(jìn)行打包。打包出sdk，這個(gè)sdk是支持多語(yǔ)言的非常強(qiáng)大，下面看看百科是怎么說(shuō)的

thrift是一個(gè)軟件框架，用來(lái)進(jìn)行可擴(kuò)展且跨語(yǔ)言的服務(wù)的開(kāi)發(fā)。它結(jié)合了功能強(qiáng)大的軟件堆棧和代碼生成引擎，以構(gòu)建在 C++, Java, Go,Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語(yǔ)言間無(wú)縫結(jié)合的、高效的服務(wù)

那么sdk有什么用呢？
這個(gè)不同的語(yǔ)言引入sdk的方式不一樣。我就以php為例?？梢允褂胏omposer來(lái)引入這個(gè)sdk。這個(gè)sdk里面包含了服務(wù)端和客戶端所需要的東西。所以服務(wù)端和客戶端都需要引入這個(gè)sdk

我們先從服務(wù)端說(shuō)起。服務(wù)端引入了sdk后會(huì)得到3個(gè)東西。

1. interface 文件（這個(gè)文件來(lái)源于之前寫(xiě)的規(guī)定入?yún)⒊鰠⒌姆椒ǎ?/li>
2. 入?yún)?shù)據(jù)類(lèi)
3. 出參數(shù)據(jù)類(lèi)

那么現(xiàn)在服務(wù)端就可以根據(jù)自己的業(yè)務(wù)去實(shí)現(xiàn)功能了。首先繼承這個(gè)interface接口。實(shí)現(xiàn)我們?cè)O(shè)計(jì)的GetUserInfo這個(gè)方法。什么查數(shù)據(jù)庫(kù)啊，模型啊，DB啊之類(lèi)的就不介紹了。注意兩個(gè)地方
1）入?yún)?duì)象上的數(shù)據(jù)。既然是編寫(xiě)服務(wù)端接口，那么入?yún)⒗锟隙ㄊ怯形覀冃枰臄?shù)據(jù)的。首先取出數(shù)據(jù)
2）出參對(duì)象。當(dāng)我們把數(shù)據(jù)從數(shù)據(jù)庫(kù)中查出來(lái)了之后，我們要按照出參對(duì)象上的屬性來(lái)構(gòu)建這個(gè)對(duì)象。然后一定要返回這個(gè)數(shù)據(jù)對(duì)象

那么現(xiàn)在所有的事情都做好了之后。在客戶端又如何調(diào)用呢？
首先我們之前有提到過(guò)，客戶端也要引入sdk。這個(gè)sdk中對(duì)每個(gè)服務(wù)都有一個(gè)類(lèi)文件。這個(gè)類(lèi)文件中就有調(diào)用某個(gè)方法的實(shí)現(xiàn)

示例如下。調(diào)用實(shí)際很簡(jiǎn)單。首先引入某個(gè)sdk，然后在自己的方法里構(gòu)造入?yún)?duì)象。然后實(shí)例化接口類(lèi)，調(diào)用接口類(lèi)中的某個(gè)方法，然后就直接接收調(diào)用結(jié)果就完了。體驗(yàn)非常接近調(diào)用自己的一些service方法。只不過(guò)在這個(gè)調(diào)用背后其實(shí)是向外部進(jìn)行了一次通信

image.png

感想

其實(shí)一開(kāi)始，我認(rèn)為這種方式來(lái)開(kāi)發(fā)效率是真的底下。寫(xiě)個(gè)增刪改查這種簡(jiǎn)單的東西都要花很多時(shí)間。不過(guò)站在一個(gè)企業(yè)，特別是大企業(yè)來(lái)說(shuō)。這樣做的好處還是很多的。

1. 支持多語(yǔ)言（thrift支持很多語(yǔ)言，多語(yǔ)言之前無(wú)痛調(diào)用）。這樣就可以避免因?yàn)檎Z(yǔ)言問(wèn)題去寫(xiě)重復(fù)的業(yè)務(wù)邏輯
2. 項(xiàng)目解耦，比如多個(gè)項(xiàng)目都去調(diào)用一個(gè)服務(wù)端thrift接口。這個(gè)服務(wù)端查詢(xún)數(shù)據(jù)庫(kù)壓力比較大。那么運(yùn)維就去優(yōu)化這一臺(tái)服務(wù)器或集群就好了。而不用去關(guān)注每個(gè)不同的調(diào)用方的性能
   3.由于sdk是已版本形式迭代。你寫(xiě)了一個(gè)新功能，你只需通知調(diào)用方，類(lèi)名方法名和入?yún)⒊鰠⑿问?。調(diào)用方的程序員直接更新下sdk的版本就好了。這樣更適合多人協(xié)助
3. 調(diào)用規(guī)范。在客戶端向服務(wù)端通信時(shí)。會(huì)自動(dòng)校驗(yàn)，參數(shù)數(shù)據(jù)結(jié)構(gòu)。調(diào)用來(lái)源是否合法等等。這意味著，每次從客戶端傳遞的數(shù)據(jù)都是完整有效的。如果是參數(shù)不對(duì)或者來(lái)源不合法的話是不會(huì)請(qǐng)求到服務(wù)端的。這樣也保證了服務(wù)端的性能不會(huì)被浪費(fèi)，每次的請(qǐng)求都是有效且合法的。

尾巴

一個(gè)龐大的項(xiàng)目是難以維護(hù)的，再高級(jí)的程序員也難以維護(hù)超大的項(xiàng)目。將一個(gè)超大的項(xiàng)目拆分，各自獨(dú)立建設(shè)會(huì)更利于項(xiàng)目的維護(hù)與開(kāi)發(fā)。雖然在網(wǎng)絡(luò)請(qǐng)求方面效率低了一點(diǎn)。卻換來(lái)更靈活更健康的項(xiàng)目狀態(tài)。微服務(wù)的概念已經(jīng)被越來(lái)越多的公司所接受。我也是初次學(xué)習(xí)到這樣的思想。如果有寫(xiě)的不對(duì)地方。希望能有大神指出，感激不盡謝謝

以上