框架的API設計

設計的目的是服務**編寫的時候無論在何處，只需要簡單的呼叫框架api即可獲取資源，無需其他任何設定。

例如在資料**服務的**中使用context.logger()返回是的資料**服務的日誌，而在管控服務中呼叫context.logger()返回的是管控服務的日誌。

不同的服務之間的資源不同，所以肯定有乙個map用來裝著不同服務的資源，map的索引即是服務的唯一索引。

同乙個服務下，任何地方能直接獲取到自己服務的資源，這也意味著在服務的任何地方都儲存著當前服務的唯一索引。

解決辦法：

不同的服務之間，除了服務的主鍵id不同以外，每個服務都有自己classloader，因此classloader可以作為服務的索引，每個執行緒都有自己的contextclassloader，當前執行緒新執行的子執行緒會直接繼承父執行緒的contextclassloader，因此我們只需要在服務的啟動執行緒設定好contextclassloader，服務在此執行緒上開啟的新執行緒均會繼承相同的contextclassloader，這樣就實現了在乙個服務的任何地方都可以通過thread.currentthread().getcontextclassloader()來獲取當前服務的索引。

public

class
context
//獲取當前執行緒所在服務的資源
private
static iresource getresource()
//獲取當前執行緒所在服務的日誌
public
static ilogger logger()
...//獲取其他資源
}

框架API設計相關的碎言

框架的api設計，應該是乙個從粗粒度到細粒度的精煉過程，而不能一開始就提供細粒度卻沒有考慮周全的api，這樣的情況會 1 造成框架使用者的窘迫，當框架實現中存在bug的時候，使用者將難以繞過這些bug而前行，只能等待框架的bug fix版本的發布 2 造成框架的頻繁而倉猝的公升級，難免又引入新的bu...

api 設計良好 API 的特點

這裡 的 api 均為系統邊界的api設計，而對於內部 api 來說不在 範圍之內。變動困難 api 就像乙個人一樣，我們和乙個api打交道的時候需要了解這個人的特性偏好等，有的人很好相處，而有的人讓人很頭疼，尤其是你不得不和他打交道的時候。和人一樣，如果你不得不和他打交道，要改變他的秉性是很痛苦的...

服務API設計 之 API設計原則

對接xx業務時，xx業務具備的功能和api全靠跑業務負責人那反覆逐個詢問 確認。用哪個api 怎麼用 有沒有限制 等等 各個業務間，甚至同一業務內，api風格不統一。xx業務api效能方面未知。隨著業務的演進，開放的api持續在增加，但類同的很多 api編碼規範迫在眉睫 自解釋 易學習 易使用 難誤...