今天聊一聊后臺(tái)工程師（java初級工程師）的工作日常，微服務(wù)還有API。
導(dǎo)語：哎日常工作不就是增刪改查嗎！
其實(shí)初級工程師的日常工作還真是增刪改查。不過卻也沒那么簡單。談一下需要做好的工作吧
接口設(shè)計(jì)
代碼設(shè)計(jì)
API設(shè)計(jì)其實(shí)不是一個(gè)簡單的活，業(yè)界認(rèn)可的就是restful 規(guī)范，其次，就是接口文檔。要是你能夠定義一套規(guī)范的restful 的api，那層次算特別高的了。
其次，要維護(hù)一套文檔。
再者，api是對外的，對內(nèi)的，就是你的代碼結(jié)構(gòu)，一個(gè)好的項(xiàng)目就是23種設(shè)計(jì)模式的有機(jī)結(jié)合。用好這寫設(shè)計(jì)模式，也是需要時(shí)間沉淀的。
最后，就是微服務(wù)的劃分。其實(shí)微服務(wù)的劃分這個(gè)有點(diǎn)屬于架構(gòu)師的工作范疇了，常見是基于業(yè)務(wù)領(lǐng)域的服務(wù)劃分，劃分過細(xì)的話，分分鐘一個(gè)保存操作，涉及三四個(gè)分布式事務(wù)。
本篇就討論一下微服務(wù)API吧
一、微服務(wù)的API設(shè)計(jì)
1.1.思想
之前領(lǐng)導(dǎo)是一個(gè)特別牛逼的偏前端的全棧工程師，那時(shí)候，我剛畢業(yè)對于一些api的設(shè)計(jì)理解有點(diǎn)偏，就是有點(diǎn)像是亂開接口。參數(shù)類型等等，定義不規(guī)范。那時(shí)候，給我看了幾家他就職過的大廠的接口的demo，引導(dǎo)我那種design在哪種場景更加合適。還有小接口，大接口。
總結(jié)起來就是：
不是為了一個(gè)功能方法而去開放一些需要的接口，而是為了一個(gè)功能模塊，我們后臺(tái)需要去開一套維度合適的接口。
有一個(gè)特別快的提升方式，跟一個(gè)前端工程師交朋友，每天問他，現(xiàn)在給的接口用起來會(huì)不會(huì)更爽一點(diǎn)。
1.2.服務(wù)提供者，和消費(fèi)者
見過幾個(gè)廠的微服務(wù)架構(gòu)。其實(shí)大同小異。對于服務(wù)的提供者和消費(fèi)者，都有自己的見解。但是在我看過的幾個(gè)項(xiàng)目，也有跟其他大神討論過，可以總結(jié)出來，大概有兩種形式吧：
- 提供者既是消費(fèi)者：
- 提供者與消費(fèi)者分層：
在這里得講兩個(gè)概念，外部接口，內(nèi)部接口。
外部接口其實(shí)沒啥可解釋的。
內(nèi)部接口，就是提供給其他微服務(wù)的接口，可以理解為service層的遠(yuǎn)程實(shí)現(xiàn)，一般來說，是不對外開放。
服務(wù)提供者，就可以理解為是平時(shí)單機(jī)架構(gòu)里面的service層，
而消費(fèi)者，就是調(diào)用一或多個(gè)service，進(jìn)行業(yè)務(wù)邏輯操作，在某廠稱為business層。
消費(fèi)者開的是外部接口，提供者開的是內(nèi)部接口。
在下面的項(xiàng)目里面，其實(shí)就是提供者既是消費(fèi)者，但是，我在zuul里面沒有做控制而已。
1.3.微服務(wù)的API以及接口
對于服務(wù)的消費(fèi)者，一般寫的API，都是要遵循restful規(guī)范。
對于服務(wù)的提供者，我感覺，把他看成一個(gè)用http協(xié)議的遠(yuǎn)程接口就OK了，如果要用restful規(guī)范，會(huì)失去一定的靈活性（在做接口設(shè)計(jì)的時(shí)候是可以體會(huì)得到的）。
從兩個(gè)維度說吧：
- 框架方面
比如說，阿里的dubbo，新浪的motan，的服務(wù)提供者都是RPC框架實(shí)現(xiàn)的。你說要基于restful 嗎？
- 其他方面（分布式事務(wù)等）
先普及一下分布式事務(wù)：
一般來說，微服務(wù)架構(gòu)，多數(shù)使用的是柔性事務(wù)（基于業(yè)務(wù)代碼的事務(wù)，不是基于資源的事務(wù)）有三種：
- 基于消息的最終一致性事務(wù)
- TCC事務(wù)
- 最大努力通知型事務(wù)
比如說，一個(gè)提供者接受到一個(gè)請求，需要跨服務(wù)保存操作。這樣就涉及到分布式事務(wù)，使用消息的最終一致性事務(wù)的話，是發(fā)一條消息過去，而用TCC的話，一個(gè)保存操作又有了一個(gè)取消接口，確認(rèn)接口。一個(gè)服務(wù)提供者，寫的接口也要遵循 restful design的話，******，所以說，不要太較真，物極必反。
接口校驗(yàn)
其實(shí)過濾器是公司統(tǒng)一的，其次就是一些接口校驗(yàn)了。其實(shí)也沒啥好說的。一般@Vaild校驗(yàn)的都是格式，長度，大小之類的。判空的一般會(huì)在Controller里面的業(yè)務(wù)邏輯里面做。
異常處理
其實(shí)更準(zhǔn)確的來說，是狀態(tài)碼。
狀態(tài)碼處理的話主要分兩種，一種是消費(fèi)者的，一種是提供者的。
消費(fèi)者的狀態(tài)碼：
其實(shí)就是給前端的狀態(tài)碼，比如說，有時(shí)候，你點(diǎn)擊一個(gè)按鈕，顯示，服務(wù)器繁忙請稍后再試，很多時(shí)候，前端顯示的提示信息，都是根據(jù)后臺(tái)給的狀態(tài)碼，還有信息顯示的。
提供者的狀態(tài)碼：
在Spring Cloud中，可以理解為Feign Client調(diào)用服務(wù)失敗，要怎么處理，比如說，你去調(diào)一另外一個(gè)服務(wù)查詢，返回500，其實(shí)可能有時(shí)候，那個(gè)服務(wù)當(dāng)?shù)袅?，這時(shí)候，你重試，再去調(diào)一次（基于負(fù)載均衡，調(diào)的是另外一臺(tái)服務(wù)器）可能就OK了，但是，如果，返回個(gè)不存在，這時(shí)候你重試是沒有意義的。
最后上代碼
allen-api-demo用到了 SPRING MVC + SWAGGER + OAUTH
水平有限，只是寫了一些API文檔的維護(hù)，校驗(yàn)，異常處理，接口權(quán)限，返回視圖的簡要使用方式。
再來一個(gè)今年一月多寫的
flexible-transaction-event-demo 基于消息的最終一致性事務(wù)
TCC的，看了挺多設(shè)計(jì)方法，也有再加一個(gè)事務(wù)的協(xié)調(diào)者的。后面再慢慢分享出來吧。
結(jié)語
自己的學(xué)習(xí)路程是先打好基礎(chǔ)，然后分課題學(xué)習(xí)。我覺得大概我研究完這幾個(gè)課題應(yīng)該就有中級工程師水準(zhǔn)了
- 軟件工程
- API設(shè)計(jì)
- 分布式事務(wù)
- 消息中間件
- 數(shù)據(jù)庫
- 設(shè)計(jì)模式
自己研究的比較好的課題是API設(shè)計(jì)，然后自己花的最多時(shí)間去吃的是分布式事務(wù)。再者，
