10月30日，全球權威資料調研機構idc正式發布《idcmarketscape:中國devops雲市場2019，廠商評估》報告。京東雲憑藉豐富的場景和實踐能力，以及高質量的服務交付和平台穩定性，取得優異的成績，躋身「major players」（核心廠商）位置。京東雲devops能力起源於自身的業務實踐，針對京東集團的複雜業務場景打造並經受住多次618、11.11電商大促的嚴峻考驗，保證了高效高質的交付和對變化的靈活應對。能夠支援複雜場景的自動化運維需求、實現工具鏈產品與平台化產品結合，幫助客戶根據不同的需求靈活定製方案。前兩次的專題內容中，我們分別與大家分享了大型企業級監控系統的設計以及監控系統的可觀測性與資料儲存。今天，我們將通過介紹京東雲devops落地實踐，和大家繼續分享devops中另乙個重要內容：日誌查詢服務。
日誌查詢服務，是構建軟體專案的基石之一，是系統穩定執行必不可少的一部分，已然成為devops中的標配選項。這裡，我們來聊一聊京東雲翼devops平台的日誌查詢服務實踐。
本著客戶為先，全心全意為使用者服務的原則，雲翼日誌查詢服務的發展分以下幾個階段解決使用者的日誌需求：
針對使用者的這個需求，我們開發並提供了現場日誌查詢功能。
何為現場日誌？就是案發現場的日誌。案發現場一般在**呢？當然是使用者應用部署所在的主機了。
我們提供現場日誌查詢的功能，用於查詢使用者主機上的應用日誌。該功能預設支援規範目錄下的日誌查詢，且支援擴充套件的自定義路徑。
使用者自定義路徑舉例：/export/test.log，由於這個路徑對我們系統來講是「不規範」的，使用者如果需要查這個日誌資訊，就需要自己手動輸入該日誌路徑，然後再執行查詢操作。
現場日誌查詢檔案選擇示例圖
如何實現現場日誌查詢功能
想想一般我們自己要檢視主機上的日誌是怎麼做的呢？第一步往往是ssh登入到主機，然後通過grep命令查詢指定內容。是的，我們的現場日誌就是將這一過程進行了平台化，使用者在現場日誌頁面上選擇要查詢的日誌檔案，輸入要查詢的關鍵字，點查詢按鈕即可。出於安全性考慮，ssh認證我們採用金鑰認證而非密碼認證。當然了，既然通過ssh連線，那就要求使用者主機必須開放22埠。
現場日誌通過ssh查詢遇到的問題
比如有的使用者的主機是在vpc裡的，ssh直接訪問不到，怎麼辦呢？想想辦法這個問題是可以解決的，那就是配置**，這樣就導致漸漸地要維護一堆的**配置。
改進措施
隨著雲翼內部新的控制系統zero的出現（zero是一套控制系統，通過給使用者主機上的zero-agent下發任務實現對使用者主機的一些操作），現場日誌查詢有了新的實現方式，可以通過呼叫控制系統api，用控制系統下發任務的方式來實現日誌查詢，這樣採用http的連線方式替代之前的ssh，不再依賴金鑰，也不再需要再維護一堆的ssh**配置了。嗯，感覺一下清爽了好多。
新的困境
改變實現方式後，發現乙個新的問題，就是使用者單條日誌太大的情況下，查詢資料量如果超過zero-agent一次傳輸資料量的限制會導致查詢失敗，這裡就需要做個權衡了，要麼使用者調整日誌長度，要麼減小一頁的資料展示條數，再要麼可以考慮換一種查詢方式，比如用下面將要介紹的歷史日誌查詢，當然了，這只是權宜之計，歷史日誌功能並不是為了解決這個問題才產生的。
為此，雲翼的歷史日誌查詢功能應運而生。我們期望歷史日誌支援最近7天的日誌檢索。
既然要集中檢索，那我們首先需要及時把日誌資料採集走，進行集中儲存。這裡需要使用者做乙個日誌訂閱的操作，其實就是告訴日誌服務要採集哪個應用下的哪個日誌檔案的資料。
日誌資料流向圖：
上圖反映了使用者訂閱後，使用者日誌資料的流向情況。可以看到資料儲存涉及兩種介質，一種是kafka，一種是es，資料先快取到kafka，最終流向es。elasticsearch簡稱es，是乙個開源的分布式搜尋引擎，我們的歷史日誌查詢功能正是借助於es強大的搜尋能力實現的。
下面依次介紹一下上圖中的log-agent、fwd和indexer模組。
es索引介紹
es儲存離不開索引，最初我們的索引是按照天的粒度來建立的，一天乙個索引，例如：index-log-2019-10-21。但是隨著日誌量的增加，按天索引，每次查詢時，搜尋範圍太大，會導致一次查詢特別慢，使用者體驗非常不好。為了提公升查詢效率，後來就把索引改成了小時粒度，例如：index-log-2019-10-21-13。
索引時間如何確定
看完es索引介紹，有人可能會有疑惑，既然是按時間索引，這個時間具體是怎麼取的呢？從使用者的日誌訊息中解析的嗎？不是的。使用者的日誌，時間格式各不相同，從使用者日誌中解析時間顯然是不現實的。
難道是按照當前的搬運時間來確定索引？這樣的話，在資料處理不及時，kafka訊息有積壓的情況下，使用者日誌中的時間和索引的時間就很可能不一致了呀，比如15點的資料，可能會放到16點的索引中，這樣在搜尋15點的資料的時候是搜不到期望的資料的。
這裡要說明一下，我們log-agent採集的每條資料，除了日誌內容外，都會帶有一些元資訊，比如部門名稱、應用名、日誌檔案路徑，time時間戳等，這裡的時間戳記錄的是日誌採集時的時間，由於是實時採集，這個時間和使用者應用日誌中的時間可以看作是幾乎相等的。在索引資料前，先解析出time時間戳，通過這個時間戳來確定具體的索引。這樣即使在kafka訊息有積壓的情況下，也能保證日誌資料可以正確存放到期望的索引中。
歷史日誌查詢示例圖
歷史日誌面臨的問題
隨著日誌量的增多，有乙個比較尷尬的問題，就是es儲存資源會出現不足的情況。這是乙個需要我們和使用者一起努力來解決的問題。
之前我們將採集到的資料存放到了kafka，資料來源有了，接下來就是把資料拉下來進行合併儲存的問題了。對，期初我們選擇的儲存介質是hdfs（es是檢索利器，且儲存成本太高，用做長久儲存顯然是不現實的）。
日誌轉存（hdfs->oss）遇到的問題及解決辦法
這確實是比較典型的使用者需求，為了滿足使用者的這個需求，我們開發了自定義日誌目的地的功能。
自定義日誌目的地，顧名思義，就是讓使用者自己來指定將日誌存放到**，然後使用者在做訂閱操作的時候，指定這個目的地名稱即可。
目前支援的日誌目的地有兩種型別：fwd和kafka。
從使用情況來看，目前kafka型別的日誌目的地佔絕大多數。
微服務實踐歷程
微服務概念的出現已經有很多年了，有多少公司在真正使用微服務，今天就把我這幾年對微服務的一點感受和大家分享下 首先，在系統建立之初，有乙個問題，到底要不要按照微服務的架構來開始專案？這個時候如果我們是接觸的乙個比較熟悉的行業 熟悉的業務，或者說業務架構師對這一行比較了解，那麼可以考慮進行微服務的設計，...
短鏈結服務實踐
實現 功能擴充套件 分布式高可用 其他目標 經過網上的查詢和參考，大致兩種方式。第二種方式 系統內自己實現。具體實現，需要看業務場景。推薦參考這篇文章 如何將乙個長url轉換為乙個短url？細節的實現方式，就直接看這篇文章就行。或者直接看 具體 參考 中 fun.gengzi.codecopy.bu...
Abp vNext微服務實踐 服務通訊
服務通訊是微服務架構中必不可少的功能，服務通訊的效率決定了微服務架構的優略。常用的微服務通訊策略有兩種，分別是rpc http，其中rpc以grpc框架為代表使用者最多。abp vnext微服務架構中當然也有服務通訊策略，採用的是http方式進行服務通訊。雖然grpc高效安全，但是相關的.net框架...