sudo yum install epel-release

find -name nginx

yum remove nginx

sudo yum install nginx

sudo systemctl start nginx
sudo systemctl enable nginx #可用

echo "/usr/local/nginx/sbin/nginx" >> /etc/rc.local

ifconfig

cd /etc/nginx/ #定位到nginx安裝目錄
vim nginx.conf #通過vim打開nginx.conf配置文件進行配置

upstream 192.168.119.128{
    server 192.168.119.1:8081;
    server 192.168.119.1:8082;
}

server{
    listen   80;
    server_name  192.168.119.128;
    location /{
        proxy_pass   //192.168.119.128;
    }
    
}

service nginx restart

 1 public ActionResult Index()
 2 {
 3       if (this.HttpContext.Session["mysession"] == null)
 4       {
 5                 this.HttpContext.Session["mysession"] = DateTime.Now.ToString("yyyy-MM-dd hh:mm:ss");
 6       }
 7  
 8        this.HttpContext.Response.Cookies.Add(new HttpCookie("mycookies")
 9        {
10                     Expires = DateTime.Now.AddDays(1),
11                     Value = HttpContext.Server.MachineName + "||" + DateTime.Now.ToString()
12        });
13        return View();
14 }

 1 public ActionResult GetSession()
 2 {
 3       if (this.HttpContext.Session["mysession"] != null)
 4       {
 5                 ViewBag.DD = this.HttpContext.Session["mysession"].ToString();
 6                 ViewBag.SCode = this.HttpContext.Session["mysession"].GetHashCode().ToString();
 7                 ViewBag.SID = this.HttpContext.Session.SessionID;
 8        }
 9  
10         ViewBag.CVAL = System.Web.HttpContext.Current.Request.Cookies["mycookies"].Value;
11         ViewBag.CID = System.Web.HttpContext.Current.Request.Cookies["mycookies"].Name;
12         ViewBag.CDO = System.Web.HttpContext.Current.Request.Cookies["mycookies"].Domain;
13      return View();
14 }

 1 @{
 2     ViewBag.Title = "GetSession";
 3 }
 4 
 5 <h2>站點：A -- GetSession</h2>
 6 <span>站點：A</span>
 7 <br />
 8 <span>Session Value: @ViewBag.DD</span>
 9 <br/>
10 <br />
11 <span>Session SCode: @ViewBag.SCode</span>
12 <br />
13 <br />
14 <span>Session ID: @ViewBag.SID</span>
15 <br />
16 <br />
17 <span>Cookies ID: @ViewBag.CID</span>
18 <br />
19 <br />
20 <span>Cookies Values: @ViewBag.CVAL</span>
21 <br />
22 <br />
23 <span>Cookies Values: @ViewBag.CDO</span>

         Install-Package Microsoft.Web.RedisSessionStateProvider

  3、Nginx服務狀態情況
     在centos終端輸入命令service nginx status 查看情況，確保服務正常運行。
  4、Web站點部署

           部署兩個站點分別為：

　　   站點A：埠為8081，

　　   站點B：埠為8082，

      二、功能效果展現

             直接開啟兩個URL鏈接，確認兩個網頁的獲取到的session和cookies都是一致。

3.2、Net分散式系統之三：Keepalived+LVS+Nginx負載均衡之高可用      

上一篇寫了nginx負載均衡，此篇實現高可用（HA）。系統整體設計是採用Nginx做負載均衡，若出現Nginx單機故障，則導致整個系統無法正常運行。針對系統架構設計的高可用要求，我們需要解決Nginx負載均衡出現單機故障時，系統正常運行的需求。所以系統架構引入Keepalived組件，實現系統高可用。

　　一、Keepalived介紹

 　　      Keepalived是分散式部署系統解決系統高可用的軟體，結合LVS（Linux Virtual Server）使用，其功能類似於heartbeat，解決單機宕機的問題。

      二、Keepalived技術原理

             keepalived是以VRRP協議為實現基礎的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗餘協議。通過VRRP協議結合LVS，對組群伺服器監控情況，若master出現宕機情況，則將VIP漂移到backup機上。實現了分散式系統高可用。可以理解

            為：keepalived是LVS的管理軟體，根據監控情況，將宕機伺服器從ipvsadm移除掉。

      三、Keepalived+LVS+Nginx實現系統高可用

3.3、Net分散式系統之四：RabbitMQ消息隊列應用

       消息通訊組件Net分散式系統的核心中間件之一，應用與系統高並發，各個組件之間解耦的依賴的場景。本框架採用消息隊列中間件主要應用於兩方面：一是解決部分高並發的業務處理；二是通過消息隊列傳輸系統日誌。目前業界使用較多的消息隊列組件有

       RabbitMQ、ActiveMQ、MSMQ、kafka、zeroMQ等，本文對系統架構之MQ Component詮釋，並採用RabbitMQ作為消息隊列中間件。

       一、RabbitMQ介紹

              RabbitMQ是一款基於AMQP（消息隊列協議），由Erlang開發的開源消息隊列組件。是一款優秀的消息隊列組件，他由兩部分組成：服務端和客戶端，客戶端支援多種語言的驅動，如：.Net、JAVA、Erlang等。RabbitMQ與其他消息隊列組件性能比較，在此

              不作介紹，網上有大把的資料。

       二、RabbitMQ原理簡介              

       RabbitMQ中間件分為服務端（RabbitMQ Server）和客戶端（RabbitMQ Client），服務端可以理解為是一個消息的代理消費者，客戶端又分為消息生產者（Producer）和消息消費者（Consumer）。

　　1、消息生產者（Producer）：主要生產消息並將消息基於TCP協議，通過建立Connection和Channel，將消息傳輸給RabbitMQ Server，對於Producer而言基本就完成了工作。

　　2、服務端（RabbitMQ Server）：主要負責處理消息路由、分發、入隊列、快取和出列。主要由三部分組成：Exchange、RoutingKey、Queue。

　　  （1）Exchange：用於接收消息生產者發送的消息，有三種類型的exchange：direct, fanout,topic，不同類型實現了不同的路由演算法；

　　　　A. direct exchange：將與routing key 比配的消息，直接推入相對應的隊列，創建隊列時，默認就創建同名的routing key。

　　　　B. fanout exchange：是一種廣播模式，忽略routingkey的規則。

　　　　C. topic exchange：應用主題，根據key進行模式匹配路由，例如：若為abc*則推入到所有abc*相對應的queue；若為abc.#則推入到abc.xx.one ,abc.yy.two對應的queue。

　　  （2）RoutingKey：是RabbitMQ實現路由分發到各個隊列的規則，並結合Binging提供於Exchange使用將消息推送入隊列；

　　  （3）Queue：是消息隊列，可以根據需要定義多個隊列，設置隊列的屬性，比如：消息移除、消息快取、回調機制等設置，實現與Consumer通訊；

　　3、消息消費者（Consumer）：主要負責消費Queue的消息，同樣基於TCP協議，通過建立Connection和Channel與Queue傳輸消息，一個消息可以給多個Consumer消費；

　　4、關鍵名詞說明：Connection、Channel、Binging等；

　　  （1）Connection：是建立客戶端與服務端的連接。

　　  （2）Channel：是基於Connection之上建立通訊通道，因為每次Connection建立TCP協議通訊開銷及性能消耗較大，所以一次建立Connection後，使用多個Channel通道通訊減少開銷和提高性能。

　　  （3）Binging：是一個捆綁定義，將exchange和queue捆綁，定義routingkey相關策略。

      三、RabbitMQ應用

           本章節描述，web應用生產的日誌，通過rabbitmq傳輸，然後日誌服務接收消息隊列的消息。

           具體樂意產考網路，此處略過。

3.4、Net分散式系統之五：C#使用Redis集群快取

         本文介紹系統快取組件，採用NOSQL之Redis作為系統快取層。        

        一、背景

　　系統考慮到高並發的使用場景。對於並發提交場景，通過上一章節介紹的RabbitMQ組件解決。對於系統高並發查詢，為了提供性能減少資料庫壓力，我們加入快取機制，可以不同層次加入快取支援，本文主要介紹應用服務層和數據層之間加入快取機制提升性能。

       業界快取組件有Redis、Memcached、MemoryCache。本系統採用Redis快取組件，有些系統將Redis當作MQ使用，此場景本系統用RabbitMQ，Redis主要用於系統快取應用。

       

        二、Redis簡介

　　Redis是一個開源的Key-Value資料庫，使用C語言編寫、支援網路、可基於記憶體亦可持久化的NOSQL資料庫，並提供多種語言的API，例如：Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby等語言驅動。自Redis3.0開始支援集群方案。

 　  相關Redis Cluster 原理在此不多介紹，網路上有很多資料。

       三、Redis集群應用

           （一）環境介紹

　　　　        本系統基於Linux之CentOS搭建Redis3.0集群。將三個Instance部署於一台虛擬機，應用部署於windows平台。

                      

 

 

            （二）安裝Redis

            （三）配置Redis集群  

3.5、Net分散式系統之五：微服務架構

        一、背景&問題               

             之前框架是一個基於SOA思想設計的分散式框架。各應用通過服務方式提供使用，服務之間通訊是RPC方式調用，具體實現基於.NET的WCF通訊平台。框架存在如下2個問題：

　　1、高並發處理能力不足。一旦高並發請求，可能出現多個服務待定處理，導致整個系統出現瓶頸。

　　2、隨著移動端廣泛應用，服務不能靈活支援APP應用。

　　3、系統持續集成部署過於繁瑣，遇到問題不好定位。

　　     基於以上存在問題升級框架，結合當前主流的架構思想，將系統進行服務化思維，就是「微服務架構」。

       

    二、微服務架構

　　   微服務架構（Microservices Architecture）是將系統拆分為多個服務，俗稱為應用服務。應用服務實現單一、具體的業務應用功能，支援獨立部署維護，多個應用服務構建成系統。應用服務之間通過輕量級通訊框架進行，並且支援應用服務用不同技術或者平台實

          現。微服務架構是SOA架構設計思想另一種實現方式。微服務架構有如下特點：

　1、微服務架構好處

　　（1）橫向擴展應用服務提升系統並發處理能力

　　（2）應用服務獨立部署維護，有利於迭代開發升級持續部署

　　（3）架構靈活支援多種技術實現

　　（4）有利於應用服務實現高可用性

　2、微服務架構不足

　　（1）對系統設計有一定要求，尤其是拆分技術應用服務介面

　　（2）導致系統實現複雜度的提高

　　（3）需要確保系統數據一致性機制

　　（4）導致系統維護要求和成本提高

　　系統是否需要採用微服務架構進行構建是由項目需求決定。採用微服務架構進行設計構建系統，對團隊成員能力比傳統要求高，尤其是設計能力。

三、框架設計原則

　　1、可擴展：支援不修改系統功能，按需擴展伺服器資源。

　　2、高可用：支援分散式部署雙機熱備機制，滿足系統高可用性的要求。

　　3、高並發：支援快捷擴張應用服務處理能力，提升系統處理能力，滿足並發請求。

　　4、安全性：訪問安全通過統一認證訪問；資訊安全通過加解密、簽名傳輸；網路安全通過網路隔離及防火牆；數據安全通過定時備份及高容錯能力。

　　5、一致性：採用數據最終一致性策略。

四、框架總體設計

       

如圖所示，系統架構基於SOA架構設計思想，並且採用微服務架構方式進行設計和構建。將系統呈現和數據進行分離。系統呈現基於網頁進行實現，支援多種前端UI框架整合及自定義開發；數據由應用服務提供，統一通過「網關API」提供使用。架構支援通過網路層、應用層的負載均衡中間件等，實現高可用和並發處理能力。架構將一些基礎公共功能抽離構建成中間件。

　　1、網關API：應用服務通過網關API統一對外提供服務。網關API基於http協議、以restful方式提供統一服務介面，約定介面通訊協議，支援系統呈現的功能，以輕量級的通訊方式，滿足不同客戶端。網關API實現統一數據訪問許可權控制、路由應用服務、限流等功能。

　　2、消息平台：負責應用服務之間更新同步資訊，將原有系統架構分散式事務調用更新資訊的方式，調整為通過消息非同步發布/訂閱處理，保證數據最終一致性，應用服務之間降低耦合度和強依賴關係。高並發能力下，取得快取作用。

　　3、服務註冊監控中心：負責應用服務註冊發布登記，同時監控應用服務介面運行情況，支援動態控制應用服務接收請求，實現「去中心化」服務控制。組件實現服務註冊登記、監控等功能。

　　4、認證中心：負責架構訪問統一身份認證。通過用戶口令和許可權進行控制訪問。結合「網關API」實現安全訪問、限流等功能，同時實現頁面管理功能。

　　5、日誌管理系統：負責記錄系統日誌，提供服務介面和組件，業務程式碼通過非同步方式將日誌資訊傳輸到「消息平台」，日誌管理系統訂閱「消息平台」的日誌資訊進行處理存儲。同時提供日誌管理功能

　　6、快取中心：基於Redis分散式記憶體資料庫，搭建架構統一快取中心，提供統一快取服務。

五、軟體架構設計       

       如圖所示，系統架構以微服務架構方式進行開發，從切面觀察每個應用服務進行垂直獨立開發，根據職責劃分層次，從上而下分為四個層次，分別為Web層、服務介面層、業務邏輯層及數據訪問層。Web層主要負責系統功能呈現表達，直接面對用戶；服務介面層

       主要負責提供標準化服務介面，與呈現層對接；業務邏輯層主要實現應用業務邏輯，是應用服務核心部分；數據訪問層負責數據持久化，支援業務邏輯層。各層次之間通過介面進行隔離，有利於後續維護擴展，減低依賴和影響。

　　應用服務完成開發後進行集成部署。Web層將根據約定集成到Web應用容器，其餘層次構建為應用服務進行部署，並將服務介面進行註冊登記發布使用。

六、結語

　　基礎架構大致設計就這樣，還需要考慮實施部署，可以考慮雲平台彈性資源，再結合docker容器技術。

　　後續再逐步介紹相關基礎組件設計及實現原理。技術框架重於解決問題，設計依賴需求，需求來源實際業務場景。

3.6、Net分散式系統之六：微服務之API網關       

一、引言

　　隨著互聯網的快速發展，當前以步入移動互聯、物聯網時代。用戶訪問系統入口也變得多種方式，由原來單一的PC客戶端，變化到PC客戶端、各種瀏覽器、手機移動端及智慧終端等。同時系統之間大部分都不是單獨運行，經常會涉及與其他系統對接、共享數據的需求。所以系統需要升級框架滿足日新月異需求變化，支援業務發展，並將框架升級為微服務架構。「API網關」核心組件是架構用於滿足此些需求。

　　很多互聯網平台已基於網關的設計思路，構建自身平台的API網關，中國主要有京東、攜程、唯品會等，國外主要有Netflix、Amazon等。

二、業界相關網關框架

　　業界為了滿足這些需求，已有相關的網關框架。

　　1、基於nginx平台實現的網關有：KONG、API Umbrella

　　2、自研發的網關有：apigee、Zuul

三、API網關設計

　　API網關是微服務架構（Microservices Architecture）標準化服務的模式。API網關定位為應用系統服務介面的網關，區別於網路技術的網關，但是原理則是一樣。API網關統一服務入口，可方便實現對平台眾多服務介面進行管控，對訪問服務的身份認證、防報文重放與防數據篡改、功能調用的業務鑒權、響應數據的脫敏、流量與並發控制，甚至基於API調用的計量或者計費等等。組件設計如下：

　　　　

　　多種客戶端程式，例如：移動APP、PC端和智慧終端設備等。客戶端程式通過互聯網或者專網訪問API網關，由API網關統一接收請求後，通過一系列模組定位具體處理的微服務機，並將其轉發至目標服務處理，網關與微服務之間通訊是內部區域網。API網關統一規範平台對外的服務，同時充當了平台的PaaS層。如上圖所示，API網關功能結構基於管道模型和支援可插拔式的設計開發，提供統一基於http協議的WebAPI訪問介面，內部每個模組各自實現功能，包括：黑白名單、日誌、協議適配、身份認證、計流限流及路由。並且依賴「訪問認證中心、服務發布管理中心」分別實現API網關訪問許可權控制和定位目標微服務。各模組功能說明如下：

　　1、黑白名單：實現通過IP地址控制禁止訪問網關功能，此功能是應用層面控制實現，再往前也可以通過網路傳輸方面進行控制訪問。

　　2、日誌：實現訪問日誌的記錄，可用於分析訪問、處理性能指標，同時將分析結果支援其他模組功能應用。

　　3、協議適配：實現通訊協議校驗、適配轉換的功能。

　　4、身份認證：負責網關訪問身份認證驗證，此模組與「訪問認證中心」通訊，實際認證業務邏輯交移「訪問認證中心」處理。

　　5、計流限流：實現微服務訪問流量計算，基於流量計算分析進行限流，可以定義多種限流規則。

　　6、路由：路由是API網關很核心的模組功能，此模組實現根據請求，鎖定目標微服務並將請求進行轉發。此模組需要與「服務發布管理中心」通訊。「服務發布管理中心」實現微服務發布註冊管理功能，與其通訊獲得目標微服務資訊。

四、API網關部署

　　API網關是一個公共基礎組件，無狀態，可支援多套分散式部署。如下圖所示：

五、API網關實現技術

　　1、技術：框架整體基於.NET平台構建，所以API網關也暫定基於.NET4.6平台和ASP.NET WebAPI2.0框架實現。具體軟體架構就用上一篇所介紹的。

　　2、性能：部署於IIS7.0，1000個並發查詢請求，平均響應90ms。

　　可能在IIS7.0和.Net4.6平台，在大並發性能處理上會更不上，後續將考慮基於.net core進行升級開發，並部署於Linux平台。

　　API網關主要原理是相通，不同平台結合本身平台整體框架設計，可選用不同的技術實現，目前有些基於Spring MVC、node.js、Erlang技術進行研發。

六、結語

　　以上是對API網關概要進行設計，還有其他方面的內容此篇文章未討論，例如：安全性、高並發、擴展性等特性設計，同時作為平台其中一個組件，也涉及與其他組件一併協同運行。此塊內容會後續分享。

3.7、Net分散式系統之七：日誌採集系統（1）

        日誌對大型應用系統或者平台尤其重要，系統日誌採集、分析是系統運維、維護及用戶分析的基礎。

一、系統日誌分類

　　一般系統日誌可分為三大類：

　　1、用戶行為日誌：通過採集系統用戶使用系統過程中，一系列的操作日誌。

　　2、業務變更日誌：特定業務場景需要，採集某用戶在某時使用某功能，對某業務（對象、數據）進行某操作，由A變成B。

　　3、系統運行日誌：系統運行伺服器資源、網路及基礎中間件的情況進行定時採集日誌分析。

 

二、常見日誌分析應用場景

　　日誌採集分析是由需求驅動，根據某種場景的需要日誌採集，採集的日誌進行針對性的分析。一般常見的日誌分析結果應用場景有：

　　1、分析系統或者平台哪些功能是最受歡迎：什麼時候使用最多用戶使用，某個區域、某類用戶使用最多。有利於功能推廣；有利於提升伺服器資源從而提高用戶體驗。

　　2、內容推薦：根據用戶平常閱讀內容，採集相關日誌，並通過分析後，將用戶感興趣的內容系統自動推薦給用戶，從而提升用戶站粘性。

　　3、系統審計：對於應用系統，採集操作日誌、業務變更日誌，有利於備查及提供相關安全審計功能。

　　4、自動化運維：場景微服務架構的系統或者平台，對運維投入的要求高，自動化部署和運維，可以減少運維的工作量和壓力。系統運行環境日誌採集、分析，可實現預警、伺服器資源動態調配，有利於快速定位排查故障。

　　不同系統的運行環境、功能應用場景及需要採集分析日誌的需求也各不相同。日誌內容、採集方式存在多樣性，日誌數據量大，所以需要設計一套日誌採集系統，滿足日誌採集需求，支援便捷將分析結果反捕於應用功能。

三、日誌採集系統總體設計

　　基於以上日誌採集的初步分析，尤其微服務架構中，微服務治理能力、服務負載需要依賴服務日誌的採集分析，所以日誌採集子系統是微服務架構的基礎支援功能。日誌採集系統總體設計如下：

如上圖所示，根據日誌整個過程，系統由三部分組成：日誌採集、日誌存儲&分析及結果應用。日誌採集主要負責提供多種方式進行採集日誌；日誌存儲&分析主要實現分析統一存儲和訂製的場景分析日誌；結果應用實現將日誌分析結果提供服務介面或者默認的管理功能，供應用功能使用。

　　日誌採集整體過程：日誌採集後，通過在線或者離線傳輸到消息隊列，由日誌消費應用拉取後進行存儲。根據分析需要訂製自動作業任務實現日誌數據抽取、轉換、統計後，將結果數據寫入關係型資料庫。提供服務介面或者日誌查詢默認管理功能進行使用。

1、日誌採集

　　日誌採集實現三種方式進行採集日誌：

　　（1）WebAPI方式：實現基於http協議 restful方式採集日誌數據，並發送至消息隊列。主要用於提供移動端、微信公眾號及小量日誌採集使用，在NET分散式系統上可結合「API網關」使用。

　　（2）Service Proxy方式：基於log4.net優秀的日誌組件和消息隊列客戶端驅動，進行封裝為日誌記錄服務代理，提供便捷、統一的介面供應用進行使用。支援將日誌記錄到應用本地和在線實時發送至消息隊列，其中記錄到應用本地，可結合第三種方式完成應用功能日誌採集的功能。

　　（3）LCClient方式：實現客戶端批量抓取日誌數據，發送至LCServer。LCClient客戶端基於TCP協議與LCServer服務端進行通訊，基於NIO框架構建，可支援高並發處理能力。LCServer再將日誌數據寫入消息隊列。

　　日誌採集通過提供三種方式，滿足不同的業務應用場景使用採集日誌。

2、日誌存儲&分析

　　日誌存儲及分析由五部分構成：消息隊列（MQ）、日誌接收服務端（LCServer）、日誌存儲（Elasticsearch）、任務作業（Quartz.net）及關係型資料庫（MySQL）。

　　（1）消息隊列（MQ）：日誌通過消息隊列實現消息統一接收，做一道緩衝，滿足日誌數據並發接收能力。

　　（2）日誌接收服務端（LCServer）：接收LCClient客戶端批量發送日誌數據，並將其發送至消息隊列。

　　（3）日誌存儲（Elasticsearch）：選用ES做日誌存儲，主要考慮ES是一種文檔化分散式搜索服務，支援PB級的數據存儲，支援上百個節點的分散式集群能力，並且提供豐富的API使用，數據查詢方面有著優越的性能。

　　（4）任務作業（Quartz.net）：通過訂製化開發作業任務實現對ES日誌數據抽取、轉換、分析後，將結果存儲於關係型資料庫。Quartz.net中間件是業界公認的作業任務組件。

　　（5）關係型資料庫（MySQL）：實現日誌結果數據存儲，供日誌應用查詢使用。MySQL有著優越的主從複製機制，可解決單節點查詢性能瓶頸，同時提供傳統SQL腳本操作數據的能力，提供開發效率。

　　日誌數據存儲和分析後，最終目的就是提供與應用功能使用。

3、分析結果應用

　　分析結果應用主要提供服務介面和管理功能兩種方式。

　　（1）服務介面方式：基於http協議以restful方式提供介面，支援應用功能方便調用。

　　（2）管理模組方式：默認提供一套日誌查詢管理功能，方便於應用直接集成使用。

 

四、總結

　　日誌採集本身也是一個分散式系統，服務端每個節點都支援分散式集群部署，可實現高並發、高可用性。本文只是一種拋磚引玉，系統每個組件還需要深化詳細，同時也包括實施部署。

3.9、.Net微服務架構之運行日誌分析系統

一、引言

　　.Net技術棧目前還沒有像spring cloud相對完整一整微服務架構棧，隨著業務發展系統架構演進，自行構建.Net技術體系的微服務架構，配套相關核心組件。因平台基於微服務架構方式研發，每個領域服務遵循平台統一標準，各自研發，獨立部署運行，服務運行日誌均通過記錄本地文件方式進行記錄。程式日誌無法及時查閱，需登錄伺服器查看，同時不利於日誌統一管理，因研發運行日誌分析系統，進行日誌統一分析管理，便於快速定位程式運行問題及時處理，保障平台運行穩定。雖然行業上也有一些日誌架構，如較為有名的LEK（logstash, elasticsearch, kibana），因考慮到後續一些個性化的需求，還是自行研發運行日誌分析系統。

 

二、設計原則

　　系統在總體微服務架構設計思想下，遵守平台標準，並結合實際解決問題的需要，進行設計和研發，系統嚴格按照如下設計原則設計：

　　1、模組化：根據職責和歸屬明確，進行拆分模組，模組功能高度內聚。

　　2、服務化：各模組通訊，通過服務方式進行調用，服務之間通訊，遵守平台的標準。

　　3、松耦合：系統模組之間通訊，基於行業通用標準，按照「約定優於配置」思想，充分體現系統模組之間松耦合的關係。

　　4、高性能：採用非同步的方式進行記錄日誌和分析，不影響平台總體性能。

　　5、易擴展：日誌採用統一的接入方式，支援靈活擴展。

　　6、跨平台：支援不同技術語言、平台進行採集日誌。

 

三、總體架構

      如圖所示，系統基於上述設計原則，主要由五部分組成：日誌記錄、日誌採集、日誌接入、日誌分析及存儲、日誌管理服務。每部分職責定位明確，相互支援、相互協作，共同構成運行日誌分析系統。日誌記錄到本地文件，通過日誌採集器將本地日誌文件抽取後，發送至Kafka，同時由日誌分析服務進行消費、分析及存儲於elasticsearch，日誌管理服務提供於用戶查閱&分析日誌資訊。在平台統一通訊協議下，擴展運行日誌的內容，沿用Json報文格式，記錄內容包括：IP、埠、服務ID、記錄時間、日誌內容。

1、日誌報文

2、日誌記錄

　　日子記錄，支援多種日誌記錄組件：Log4.net（本系統選用）、.Net core 自帶的Nlog、微軟企業庫等，針對JAVA技術語言開發的服務，則選用log4j組件，只要按照約定規範進行列印日誌即可。將日誌資訊記錄到本地文件。

3、日誌採集

　　日誌採集，選用filebeat組件，filebeat是一個輕量級的日誌傳輸組件，其可以通過提供一種輕量級的方式來轉發和集中日誌和文件，幫助你把簡單採集和發送的事情簡單化。本質上filebeat是一個日誌資訊搬運工，不進行日誌過濾和分析工作。同時支援跨平台。

4、日誌接入

　　日誌接入，考慮日誌量在某一故障情況，可能存在較大並發接入，所以選用Kafka組件作為日誌資訊接入分析的統一入口，kafka組件是一個高性能的MQ組件，具有高並發、高可用的特性。統一接入方案，為系統提供更為靈活的採集日誌，不受限於某一平台、技術或者日誌採集組件，均可將運行日誌進行接入分析和存儲。

5、日誌分析及儲存

　　日誌分析，採用.Net Core研發，以後台服務的方式進行運行，訂閱kafka的日誌消息進行批量消費，分析程式支援橫向擴展部署於多個程式，提升日誌的消費能力，保障日誌接收能力和分析能力相當。對日誌分析後存儲於Elasticsearch（以下簡稱：ES），ES是一個高可擴展的開源全文搜索和分析引擎，它允許存儲、搜索和分析大量的數據。非常適合存儲半結構化的日誌數據，便於全文搜索日誌資訊。

6、日誌管理服務

 　　日誌管理服務，實現查詢ES中的運行日誌數據，通過WebAPI方式提供介面功能調用。本系統採用「前後分離」應用開發技術，前端介面功能採用H5+JS，後端服務以restful方式提供API介面。

四、總結

 　　根據不同應用場景和需求，選用不同的日誌分析架構或者自行研發，最終目的就是為了快速、方便捕捉系統日誌，有助於分析系統運行情況。尤其對於微服務架構大型平台，運行日誌更為重要。本文主要是將系統設計原則、思想進行記錄，同時對有需要的同學提供參考，可能再實際應用中，還有很多地方需要完善或者優化。