掘金 AMA：聽螞蟻金服高級技術專家-- 章耿談微服務、架構、日誌那些事

時間 2019-11-07

標籤 ama 螞蟻高級技術專家微服架構日誌那些欄目系統架構简体版

原文原文鏈接

第二十三期 AMA 掘金團隊請來了螞蟻金服高級技術專家-- 章耿作了爲期三天的 Ask Me Anything (AMA) 活動（活動已結束）。咱們在此精選了一些來自用戶的提問及章耿的回答。前端

提醒：本期Java、Spring、微服務主題的 AMA 還有不到 12 小時結束，歡迎前去提問，傳送門：juejin.im/pin/5cebeab…緩存

關於章耿

螞蟻金服高級技術專家--章耿，花名餘淮，目前在螞蟻金服中間件團隊服務與框架組負責開發框架與 SOFAStack 開源工做。架構

社區小夥伴精選提問

架構、技術、需求之間的關係應該是怎麼樣？ -@火雞turkey

您好，想問下你以爲架構、技術、需求之間的關係應該是怎麼樣？對於架構設計而言，應該先知足目前的需求仍是將來技術？先謝謝您的回覆框架

我一直認爲架構是隨着業務發展（需求）不斷演進而來的，不須要在十萬用戶的時候就去想好億級用戶的架構，不一樣的業務規模你選擇的技術點確定是不同的。不少人從一開始就會引入業界領先一些架構，但在較小的業務規模下反而會引入複雜度。因此對架構設計而言，知足目前的需求是必須的，可是知足的同時也要往前看看將來兩到三年會到一個什麼規模，給將來留下一些架構擴展能力（特別是一些架構平滑替換能力），這樣才能隨着業務發展一塊兒實現」可持續發展的演進式架構「。運維

成長爲架構師須要什麼樣的平臺和環境呢？ -@日立在掘金

您好，我想請教下，成長爲架構師須要什麼樣的平臺和環境呢？小公司就任，業務量就那麼大，沒有架構，至少要去大平臺麼？異步

嗯平臺和環境確定是很重要的。小型公司可能系統架構都比較簡單，每一個人負責的東西也較多，因此在小型公司你可能接觸的技術面會比較全，可是因爲業務規模在哪裏技術深度可能就不會那麼深了，若是有機會仍是需去大平臺體驗下。tcp

到底什麼樣的公司適合微服務架構？ -@西內

微服務這個概念很火，想問請教下到底什麼樣的公司適合微服務架構？例如：公司規模，項目有什麼要求？分佈式

能夠先看下」康威定律「，其實採用微服務，不是說什麼體量什麼規模才能夠用微服務架構，其實你準備的好了就能夠，不須要爲了微服務而微服務。當你的業務具有可拆分性、組織架構職責清晰，引入微服務不會給開發同窗帶來協做負擔的時候，就能夠採用微服務架構了。微服務

怎麼劃分微服務的粒度？ -@莫在逍遙

我想問下，怎麼劃分微服務的粒度，有沒有什麼相似的例子借鑑工具

其實不少地方都能看到微服務拆分的幾個原則：

單一職責、高內聚低耦合

服務粒度適中

考慮團隊結構

以業務模型切入

演進式拆分

避免環形依賴與雙向依賴

這些原則應該能夠快速套到你的實際項目裏去吧。

如何解決服務拆分後會出現微服務調用微服務的狀況，致使效率很慢的問題？ -@黑先生一號

請問，服務拆分後會出現微服務調用微服務的狀況，致使效率很慢，接口的QPS很低，這塊有什麼好的解決方案能夠分享下嗎

當服務拆分後鏈路過長是會有這樣的問題，在不改變業務代碼的狀況下，一方面能夠看下 RPC 調用方式是否有性能提高的空間（例如http換成tcp），另一方面能夠看下服務粒度是否適中，若是太細的話，能夠進行必定的服務聚合（例如不少 RPC 變成本地調用）。

組件與組件之間如何達到一個最低點的低耦合度？ -@Jack-rainbow

你好，大牛。我想諮詢下項目中業務組件及公共組件，如何管理及維護呢？在項目中編寫組件時，組件與組件之間如何達到一個最低點的低耦合度，您方便講講嗎？很是期待您的回覆。

你說的業務組件和公共組件是那種有個統一管控的地方，業務系統能夠按需選擇集成的那種嗎？若是是的話，那我以爲組件應該是依賴一個公共核心部分，而組件之間應該是儘可能是無依賴的，若是非要交互也應該是經過 spi 或者消息等進行解耦的。

微服務強依賴怎麼解決？ -@solution

微服務強依賴怎麼解決

微服務強依賴我以爲在實際過程當中應該比較常見吧。若是業務能解耦看是是否能經過 MQ 或者異步的方式解耦變成弱依賴。若是不行，那隻能經過一些服務保護機制，例如熔斷、限流、降級等措施來保證服務可用性。

微服務的優勢和帶來的好處？ -@AsyncIns

章哥，介紹一下微服務的優勢和帶來的好處。還有微服務的適用場景😀😀。謝謝章哥

微服務帶來的好處不少啊，例如：

業務邏輯更加內聚，功能易於獨立的開發維護

鬆耦合，開發部署等都獨立，方便快速迭代

能夠跨不一樣的語言、技術棧

能夠部署在低配的環境上

等等

固然微服務架構帶來的挑戰也很明顯：首先是分佈式的，那就會帶來必定的技術複雜度，還有測試和運維的複雜性，服務管理成本等；數據、存儲等數據一致性也有很多挑戰；還須要較強的技術團隊協做能力。這些一方面須要一套完整的微服務體系去保障（好在如今業界已有不少成熟的方案），另一方面也和組織結構的設置和協做息息相關。

因此微服務適用的場景就是當你以爲利大於弊的時候啦~

特別篇：大致量下的日誌管理怎麼作的架構

划水看書寫代碼：大佬能否問一下大致量下的日誌管理怎麼作的架構包括一些dump級別業務級別等等的日誌處理方式謝謝

不知道你說日誌管理是應用框架的日誌輸出管理，仍是相似 ELK 這種日誌統一管理平臺？

划水看書寫代碼：是應用框架日誌輸出管理

若是日誌是落本地磁盤的，咱們內部的一些實踐是中間件統一採用一個日誌框架（封裝了slf4j），這樣每一箇中間件和業務的日誌都輸出到了不一樣目錄。Error 日誌會輸出到了單獨的文件，方便採集和監控。不過這樣作的話若是中間件不少，目錄可能會有點多，大家實際過程當中，能夠本身權衡下，但最好業務和框架分開，Error和Info等分開。

划水看書寫代碼：那。。假設集羣裏某一臺部署的是就版本從而引起了某些用戶使用出現bug，如何快速定位相應日誌呢。由於按個人理解，咱們定位是要在同一個文件來進行查找，若是集羣數量較多，那會不會引發查找難度增長，畢竟除了機器覺得，日誌是要按時打包的，尤爲是在bug不明顯的狀況下。若是能夠將集羣中的日誌整合，就能夠經過時間節點來快速定位。

那就是不只僅輸出日誌，還須要有相似 ELK 這種方案，將日誌信息都採集到一個統一存儲裏面，再經過一些查詢等能力來定位問題。

划水看書寫代碼：最近打算寫個工具搞這個可是想問您要個建議
目前想法一種是脫離應用直接讀取日誌文件而後按照格式解析，以後將解析後的內容放到一個緩衝隊列。用多路複用的方式將隊列裏的信息寫到整合文件內。或者說交給es去管理。可是這種方式不必定會達成寫大於讀。並且讀寫文件的開銷有點重複。另外一種是從新寫個日誌管理方案，可是沒法徹底非侵入。讓日誌的出口不落實到文件，而是落實到緩存。

划水看書寫代碼：其次感受這兩種方案對於IO的消耗都比較大。

划水看書寫代碼：您以爲哪一種更合適一些