資訊專欄INFORMATION COLUMN
微服務和容器時代，研發與運維都面臨諸多挑戰，微服務在帶來良好的設計和架構理念的同時，也帶來了運維上的額外復雜性，尤其是在服務部署和服務監控上。那么，運維是如何看待微服務和容器的呢？傳統的單體應用又該如何完成微服務拆分？如何進行微服務之間的依賴關系管理？
單體應用 VS 微服務
單體應用存在如下兩個問題：一個是橫向擴展時需要整體擴展，資源分配最大化，不能按需擴展和分配資源；另一個是如果單體中有一個業務模塊出現問題，就會是全局性災難，因為所有業務跑在同一個實例中，發生異常時不具備故障隔離性，會影響整個業務系統，整個入口都會存在問題。
微服務的好處：
局部修改，局部更新。當運維對一個單體應用進行修改時，可能要先把整個包給停了，然后再去修改，而微服務只需逐步修改和更新即可；
故障隔離，非全局。單體應用是跑在一起，所以只要一個模塊有問題，其他就都會有問題。而微服務的故障隔離性、業務可持續性都非常高；
資源利用率高。單體應用的資源利用率低，而使用微服務，可以按需分配資源，資源利用率會非常高。
微服務帶來的復雜性：
微服務間較強的依賴關系管理。以前單體應用是跑在一起，無依賴關系管理，如果拆成微服務依賴關系該如何處理，比如說某個微服務更新了會不會對整個系統造成影響。
部署復雜。單體應用是集中式的，就一個單體跑在一起，部署和管理的時候非常簡單，而微服務是一個網狀分布的，有很多服務需要維護和管理，對它進行部署和維護的時候則比較復雜。
如何更好地利用資源。單體應用在資源分配時是整體分配，擴展時也是整體擴展，數量可控，而在使用微服務的情況下，需要為每一個微服務按需分配資源，那么該為每個微服務分配多少資源，啟動多少個實例呢，這也是非常大的問題。
監控管理難。以前我們用Java，就是一個單體應用，監控和管理非常簡單，因為它就是一個1，但是使用微服務它就是N個，監控管理變得非常復雜。另外是微服務之間還有一個協作的問題。
基于容器構建微服務架構
使用微服務，第一步是要構建一個一體化的DevOps平臺。如果你不使用DevOps做微服務的話，整個環境會變得非常的亂、非常的糟糕。它會給你的整個開發、測試和運維增加很多成本，所以第一步我們是提高DevOps的能力，能夠把它的開發、部署和維護進行很完美的結合，才可以說我們真正能夠享受到微服務架構的福利。
容器的出現給微服務提供了一個完美的環境，因為我們可以：
基于容器做標準化構建和持續集成、持續交付等。
基于標準工具對部署在微服務里面的容器做服務發現和管理。
透過容器的編排工具對容器進行自動化的伸縮管理、自動化的運維管理。
所以說，容器的出現和微服務的發展是非常相關的，它們共同發展，形成了一個非常好的生態圈。
持續集成與持續發布
持續集成的關鍵是完全的自動化，讀取源代碼、編譯、連接、測試，整個創建過程自動完成。我們來看一下如何用Docker、Maven、Jenkins完成持續集成。
首先是開發人員把程序代碼更新后上傳到Git，然后其他的事情都將由Jenkins自動完成。那Jenkins這邊發生什么了呢？Git在接收到用戶更新的代碼后，會把消息和任務傳遞給Jenkins，然后Jenkins會自動構建一個任務，下載Maven相關的軟件包。下載完成后，就開始利用Maven Build新的項目包，然后重建Maven容器，構建新的Image并Push到Docker私有庫中。然后刪除正在運行的Docker容器，再基于新的鏡像重新把Docker容器拉起來，自動完成集成測試。整個過程都是自動的，這樣就簡化了原本復雜的集成工作，一天可以集成一次，甚至是多次。
服務發現與負載均衡
服務發現與負載均衡使用的是Kubernetes的架構。每一個微服務都有一個IP和PORT，當調用一個微服務時，只需要知道微服務的IP，而不需要關心容器的IP，也不需要關心pod的IP。雖然每個pod也有IP和PORT，但當一個pod啟動時，就會把pod的IP和PORT注冊到服務發現模塊，再進行負載均衡。所以當多個pod啟動時，對于用戶來說還是只需要知道service的IP，不需要知道后端啟動了多少pod、IP是多少，這就解決了網絡的問題。
日志集中式管理
以前單體的情況下，單體的數量少，日志數量也相應比較少，而在微服務架構下，因為拆分成了很多微服務，相應的日志會非常多且散，這種情況下需要對日志進行集中的管理。我們可以在每個容器里跑日志監控，把所有日志采集進行集中管理和存儲，再通過簡易操作的UI界面進行索引和查詢。
監控管理
然后就是監控方面了。微服務的量是非常大的，這個時候如何有效地監控是極其重要的。我們剛開始做監控的時候，有幾百個實例對同一個關鍵字進行監控，出故障后會收到幾百條短信，因為每一個實例都會發一條短信。這時候嚴重的致命性的報警就會看不到，因為手機信息已經爆炸了，所以要對報警進行分級，精確告警，最重要的是盡量讓故障在發生之前滅亡。因此，在做監控時要對故障提前進行判斷，先自動化處理，再看是否需要人為處理，然后通過人為的干預，有效的把故障在發生之前進行滅亡。
但如果所有事情都靠人為去處理，這個量也是非常大的，所以對故障進行自動化隔離和自動化處理也很重要。我們在寫自動化故障處理的時候研究了很多常見的故障，寫了很多算法去判斷，精確到所有的故障，這樣基本的常見的故障和可以策劃處理的故障都可以自動化處理掉。
結語：
技術發展到了今天，不管是業務規模，還是機器數量都變得異常的龐大，傳統依靠人肉運維的方式變得不可取，在微服務和容器時代，運維人員和研發人員需要更加依賴機器去管理機器，這也是以后的發展方向。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129807.html
摘要：整體情況來說，歲可以從事運維工作，不過還是要考慮綜合性發展。 Linux是免費開源的操作系統，也是當下非常受歡迎的技術，而Linux運維作為此技術衍生出來的崗位，廣受大家的喜歡，越來越多的人都想要學習Linux技術。那么40歲從事Linux運維合適嗎? 現在大部分服務器使用的都是Linux系統，Linux免費、高性能...
摘要：飛貸金融科技副總裁陳定瑋大會現場，飛貸金融科技作為金融行業數據庫容器化的典型案例，為現場的容器愛好者帶來了題為金融領域數據庫生產容器化及應用的實踐經驗分享。 2019年6月20日，由Rancher Labs（以下簡稱Rancher）主辦的第三屆企業容器創新大會（Enterprise Container Innovation Conference, 以下簡稱ECIC）在北京喜來登大酒店盛...
摘要：應用的研發上線運維運營形成閉環，順利完成從對內服務到公共平臺的升級。從功能角度，只能支持靜態方式設置反向代理，然后，而平臺有服務對應的后端服務和端口是有動態調整需求。架構上是基礎組件需要進行升級，數據訪問層日志監控系統等。 介紹 ? ? ? ?MaxLeap早期是一家研發、運營移動應用和手機游戲公司，發展過程中積累了很多通用組件。這些組件很大程度幫公司在移動研發過程中節省了時間和成本，...
摘要：具體技術細節的補充中國人壽兩朵云的最底層的容器調度與管理都是使用了平臺。決定采納容器擁抱，對整個中國人壽而言都是一次重大的變革。對中國人壽這樣的傳統金融企業而言，上一個并不容易。 6月28日，Rancher Labs在北京舉辦了Container Day 2018容器技術大會。在大會上，Rancher Labs CEO及聯合創始人梁勝博士、中國人壽研發中心開發五部副總經理王川、技術處高...
摘要：華為的這種底氣正來自于其技術能力的塑造和強健。而華為云正是遺傳了華為的這種氣質，才能在成立僅一年多的時間里實現飛躍式的發展。華為云不僅繼承了華為的氣質，還將這種氣質不斷發揚光大。三十功名塵與土，一朝入云膽氣生！從1987年2萬元起家，到2017年銷售收入突破6000億元，華為三十年的奮斗與拼搏、積累與沉淀，終于厚積薄發。2017年，華為云正式入場，它要像AWS那樣開創一個新的產業。華為云的氣...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1860·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
