1. 程式人生 > >.NET Core微服務之基於Apollo實現統一配置中心

.NET Core微服務之基於Apollo實現統一配置中心

一、關於統一配置中心與Apollo

  在微服務架構環境中,專案中配置檔案比較繁雜,而且不同環境的不同配置修改相對頻繁,每次釋出都需要對應修改配置,如果配置出現錯誤,需要重新打包釋出,時間成本較高,因此需要做統一的配置中心,能做到自動更新配置檔案資訊,解決以上問題。

  Apollo(阿波羅)是攜程框架部門研發的配置管理平臺,能夠集中化管理應用不同環境、不同叢集的配置,配置修改後能夠實時推送到應用端,並且具備規範的許可權、流程治理等特性。其服務端基於Spring Boot和Spring Cloud開發,打包後可以直接執行,不需要額外安裝Tomcat等應用容器。

Apollo目前在國內開發者社群比較熱,在Github上有超過5k

顆星,在國內眾多網際網路公司有落地案例,可以說Apollo是目前配置中心產品領域No.1的產品,其成熟度和企業級特性要遠遠強於Spring Cloud體系中的Spring Cloud Config產品

  目前有針對Java和.Net的兩個客戶端供使用:

  Java客戶端不依賴任何框架,能夠運行於所有Java執行時環境,同時對Spring/Spring Boot環境也有額外支援。

  .Net客戶端不依賴任何框架,能夠運行於所有.Net執行時環境。

二、Apollo的快速安裝與基本配置

2.1 快速安裝

  Apollo GitHub中提供了一個讓我們快速上手的Quick Start,幫助我們快速在本地環境部署,啟動Apollo配置中心。這裡主要集中於針對開發環境的本地部署(單機環境),要部署到生產環境,請參考

Apollo分散式部署指南

  這裡我使用的是Windows Server的虛擬機器在本機搭的,當然你可以在你的Linux虛擬機器中搭建,另外你也可以通過Docker更快捷地部署Apollo

  Step1.準備下列軟體/環境

  Step2.陸續安裝Java JDK, MySQL與Git

  Step3.匯入指令碼(從QuickStart目錄中的sql資料夾中拷貝),匯入的結果會建立兩個資料庫:

  

  Step4.修改demo.sh中關於資料庫連線的資訊,主要是url、username與password

# apollo config db info
apollo_config_db_url=jdbc:mysql://192.168.80.70

:3306/ApolloConfigDB?characterEncoding=utf8
apollo_config_db_username=root
apollo_config_db_password=213224591

# apollo portal db info
apollo_portal_db_url=jdbc:mysql://192.168.80.70:3306/ApolloPortalDB?characterEncoding=utf8
apollo_portal_db_username=root
apollo_portal_db_password=213224591

  Step5.通過以下命令啟動(切換到quickstart的目錄中),後續可以將其作為Windows服務,不過生產環境一般用Linux。

cmd>cd C:\Apollo\apollo-build-scripts-master

cmd>demo.sh start  

  啟動後會最終顯示以下資訊:

==== starting service ====
Service logging file is ./service/apollo-service.log
Started [3099]
Waiting for config service startup.......
Config service started. You may visit http://localhost:8080 for service status now!
Waiting for admin service startup....
Admin service started
==== starting portal ====
Portal logging file is ./portal/apollo-portal.log
Started [4071]
Waiting for portal startup......
Portal started. You can visit http://localhost:8070 now!

  看到上述資訊顯示完畢,證明我們的Apollo已經成功啟動起來了,那麼我們可以去這兩個埠8080和8070去看看:

  [8070 => Apollo 配置中心管理介面,預設賬號:apollo/admin]

  

  進入之後會看到一個示例專案SampleApp,點進去可以看到其中有一個示例配置applicaiton

  

  [8080 => Eureka服務註冊&發現,和Consul類似,因為Apollo採用了Eureka作為服務註冊中心,對Apollo架構感興趣的童鞋可以閱讀波波老師的《攜程配置中心Apollo架構分析》,這裡不是本文的重點]

  

2.2 基本配置

  Step1.建立一個新專案(這裡部門可以自己在資料中編輯serverconfig表新增)

  

  Step2.預設情況下,建立新專案後有一個預設的application的Namespace,我們刪除它,然後重新建立我們要用到的配置。對於一般共用的資料庫、Redis、RabbitMQ等配置,我們一般會將其放到一個Public的配置列表中,而每個專案中私有的配置資訊(如Swagger文件的說明資訊)我們會單獨建立一個Private的配置列表給每個專案。

  下圖為建立一個共享的配置列表(在Apollo中稱為Namespace,詳細內容可以參考:Apollo核心概念之Namespace

    

  Step3.向Shared和ClientService兩個Namespace中新增Key/Value配置項(可以通過文字形式新增,速度更快),新增之後記得點擊發布,最終結果如下圖所示:

  

  [通過文字形式新增如下圖所示,當批量新增時建議採用文字形式提高效率]

  

  現在配置都有了,開始和我們的ASP.Net Core整合吧。

三、ASP.NET Core中整合Apollo

3.1 準備工作

  匯入.Net Core的客戶端package,看這個名字Com.Ctrip.Framework.Apollo.Configuration應該是Java程式設計師寫的,特別的Java Style.

PM>Install-Package Com.Ctrip.Framework.Apollo.Configuration 

  修改appsettings.json,新增apollo節點:指明apollo的AppId和Server地址 => AppId 用來標識應用身份的唯一id,Apollo客戶端針對不同的環境會從不同的伺服器獲取配置 ,MetaServer 就是客戶端獲取配置的伺服器配置

  "apollo": {
    "AppId": "MSAD",
    "MetaServer": "http://192.168.80.70:8080"
  }

3.2 更改Program.cs

  這裡主要會在啟動時讀取appsettings.json中的AppId和MetaServer來連線Apollo,並且指定要讀取哪個Namespace的配置項,這裡設定讀取兩個Namespace的配置項(Shared和ClientService)。

    public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .ConfigureAppConfiguration((hostingContext, builder) =>
                {
                    builder
                    .AddApollo(builder.Build().GetSection("apollo"))
                    .AddDefault()
                    .AddNamespace("TEST3.Shared")
                    .AddNamespace("ClientService");
                })
                .UseStartup<Startup>()
                .Build();

  Tip: Apollo對於Namespace還提供了一個類似於繼承的功能-關聯Namespace,你可以讓私有的ClientService關聯一下Shared,這樣就只需要讀取一個ClientService的Namespace就可以了。

  

3.3 更改StartUp.cs

  對於StartUp.cs,它承擔了很多初始化的注入工作,我們會在裡邊引入很多配置項,但是幸運的是我們不需要做太多更改,只是把配置項的Key換成Apollo中定義的即可。例如:

    // IoC - DbContext
    services.AddDbContextPool<ClientDbContext>(
                options => options.UseSqlServer(Configuration["DB"]));

    // Swagger
    services.AddSwaggerGen(s =>
    {
        s.SwaggerDoc(Configuration["Swagger.DocName"], new Info
        {
            Title = Configuration["Swagger.Title"],
            Version = Configuration["Swagger.Version"],
            Description = Configuration["Swagger.Description"],
            Contact = new Contact
            {
                Name = Configuration["Swagger.Contact.Name"],
                Email = Configuration["Swagger.Contact.Email"]
            }
        });
        ......
    });

  這裡通過檢視Swagger API文件來驗證一下是否讀出來了配置項Value:

  

  這時如果我們在Apollo中更改了ClientService的Swagger.Title配置項併發布之後(因為我們的Swagger在啟動時注入的,所以無法獲取實時更新的值),重啟一下ClientService,配置已經更改為下圖所示:

  

  對於需要實時獲取更新的item,我們也可以做一個測試,比如在一個Controller中獲取:

    [Route("api/Values")]
    public class ValuesController : Controller
    {
        private IConfiguration _configuration;

        public ValuesController(IConfiguration configuration)
        {
            _configuration = configuration;
        }

        [HttpGet]
        public IActionResult Get()
        {
            string title = _configuration.GetValue<string>("Service_Swagger_Title");

            return Json(title);
        }
    }

  第一次獲取Title為:

  

  在Apollo中修改Title為:CAS Premium Service API v4,併發布

  重新整理瀏覽器,已經實時更新:

  

四、小結

  本篇簡單介紹了一下統一配置中心與Apollo的基本概念,然後介紹了Apollo的快速安裝(基於QuickStart)與基本配置,最後通過與ASP.NET Core的整合演示瞭如何在專案中使用Apollo替代原有的配置檔案(appsettings.json)。當然,本篇只是一個QuickStart,更多的內容都沒有覆蓋,需要我們去看官方Wiki瞭解。Apollo目前在國內開發者社群比較熱,在Github上有超過5k顆星,在國內眾多網際網路公司有落地案例,值得我們學習和了解

參考資料

(1)min.jiang,《統一配置中心

作者:周旭龍

本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連結。

相關推薦

基於Apollo實現.NET Core服務統一配置(測試環境-單機) .NET Core服務基於Apollo實現統一配置中心

一、前言 注:此篇只是為測試環境下的快速入門。後續會給大家帶來生產環境下得實戰開發。 具體的大家可以去看官方推薦。非常的簡單明瞭。以下介紹引用官方內容: Apollo(阿波羅)是攜程框架部門研發的分散式配置中心,能夠集中化管理應用不同環境、不同叢集的配置,配置修改後能夠實時推送到應用端,並且具

.NET Core服務基於Apollo實現統一配置中心

一、關於統一配置中心與Apollo   在微服務架構環境中,專案中配置檔案比較繁雜,而且不同環境的不同配置修改相對頻繁,每次釋出都需要對應修改配置,如果配置出現錯誤,需要重新打包釋出,時間成本較高,因此需要做統一的配置中心,能做到自動更新配置檔案資訊,解決以上問題。   Apollo(阿波羅)是攜

.NET Core服務基於Consul實現服務治理

請求轉發 1.0 asp.net AC port prefix 我們 tle nan 一、Consul基礎介紹   Consul是HashiCorp公司推出的開源工具,用於實現分布式系統的服務發現與配置。與其他分布式服務註冊與發現的方案,比如 Airbnb的Smart

.NET Core服務基於Consul實現服務治理(續)

shell pla code tst 分層 編輯 set req \n 上一篇發布之後,這一篇把上一篇沒有弄到的東西補一下,也算是給各位前來詢問的朋友的一些回復吧。一、Consul服務註冊之配置文件方式1.1 重溫Consul實驗集群  這裏我們有三個Consul Serv

.NET Core服務基於Ocelot實現API閘道器服務

一、啥是API閘道器?   API 閘道器一般放到微服務的最前端,並且要讓API 閘道器變成由應用所發起的每個請求的入口。這樣就可以明顯的簡化客戶端實現和微服務應用程式之間的溝通方式。以前的話,客戶端不得不去請求微服務A(假設為Customers),然後再到微服務B(假設為Orders),然後是微服

.NET Core服務基於Exceptionless實現分散式日誌記錄

一、Exceptionless極簡介紹   Exceptionless 是一個開源的實時的日誌收集框架,它可以應用在基於 ASP.NET,ASP.NET Core,Web API,Web Forms,WPF,Console,ASP.NET MVC 等技術開發的應用程式中,並且提供了REST介面可以應

.NET Core服務基於MassTransit實現資料最終一致性(Part 2)

一、案例結構與說明   在上一篇中,我們瞭解了MassTransit這個開源元件的基本用法,這一篇我們結合一個小案例來了解在ASP.NET Core中如何藉助MassTransit+Quartz.Net來實現資料的最終一致性。當然,實現資料的最終一致性有很多方案,這裡只是舉一種我所學到的比較簡單易於學習

.NET Core服務基於MassTransit實現資料最終一致性(Part 1)

一、預備知識:資料一致性   關於資料一致性的文章,園子裡已經有很多了,如果你還不瞭解,那麼可以通過以下的幾篇文章去快速地瞭解瞭解,有個感性認識即可。   必須要了解的點:ACID、CAP、BASE、強一致性、弱一致性、最終一致性。      CAP理論由加州大學伯克利分校的計算機

.NET Core服務基於Ocelot實現API閘道器服務(續)

一、負載均衡與請求快取 1.1 負載均衡   為了驗證負載均衡,這裡我們配置了兩個Consul Client節點,其中ClientService分別部署於這兩個節點內(192.168.80.70與192.168.80.71)。   為了更好的展示API Repsonse來自哪個節點,我們更改一下

.NET Core服務基於Steeltoe使用Eureka實現服務註冊與發現

一、關於Steeltoe與Spring Cloud    Steeltoe is an open source project that enables .NET developers to implement industry standard best practices when b

.NET Core服務基於Steeltoe整合Zuul實現統一API閘道器

一、關於Spring Cloud Zuul   API Gateway(API GW / API 閘道器),顧名思義,是出現在系統邊界上的一個面向API的、序列集中式的強管控服務,這裡的邊界是企業IT系統的邊界。   Zuul 是Netflix 提供的一個開源元件,致力於在雲平臺上提供動態路由,監

.NET Core服務基於Steeltoe使用Zipkin實現分散式追蹤

一、關於Spring Cloud Sleuth與Zipkin   在 SpringCloud 之中提供的 Sleuth 技術可以實現微服務的呼叫跟蹤,也就是說它可以自動的形成一個呼叫連線線,通過這個連線線使得開發者可以輕鬆的找到所有微服務間關係,同時也可以獲取微服務所耗費的時間, 這樣就可以進行微服

.NET Core服務基於Jenkins+Docker實現持續部署(Part 1)

一、CI, CD 與Jenkins   網際網路軟體的開發和釋出,已經形成了一套標準流程,最重要的組成部分就是持續整合(Continuous integration,簡稱 CI) => 持續整合指的是,頻繁地(一天多次)將程式碼整合到主幹。   它的好處主要有兩個: 快速發現錯

.NET Core服務基於App.Metrics+InfluxDB+Grafana實現統一效能監控

一、關於App.Metrics+InfluxDB+Grafana 1.1 App.Metrics      App.Metrics是一款開源的支援.NET Core的監控外掛,它還可以支援跑在.NET Framework上的應用程式(版本 >= 4.5.2)。官方文件地址:https://ww

.NET Core服務基於Polly+AspectCore實現熔斷與降級機制

一、熔斷、降級與AOP 1.1 啥是熔斷?   在廣義的解釋中,熔斷主要是指為控制股票、期貨或其他金融衍生產品的交易風險,為其單日價格波動幅度規定區間限制,一旦成交價觸及區間上下限,交易則自動中斷一段時間(“熔即斷”),或就此“躺平”而不得超過上限或下限(“熔而不斷”)。   而對於微服務來說,

.NET Core服務基於Ocelot+Butterfly實現分散式追蹤

一、什麼是Tracing?   微服務的特點決定了功能模組的部署是分散式的,以往在單應用環境下,所有的業務都在同一個伺服器上,如果伺服器出現錯誤和異常,我們只要盯住一個點,就可以快速定位和處理問題,但是在微服務的架構下,大部分功能模組都是單獨部署執行的,彼此通過匯流排互動,都是無狀態的服務,這種架構下,

.NET Core服務基於Ocelot+IdentityServer實現統一驗證與授權

一、案例結構總覽  這裡,假設我們有兩個客戶端(一個Web網站,一個移動App),他們要使用系統

.NET Core服務基於Steeltoe使用Hystrix熔斷保護與監控

一、關於Spring Cloud Hystrix      在微服務架構中,我們將系統拆分為很多個服務,各個服務之間通過註冊與訂閱的方式相互依賴,由於各個服務都是在各自的程序中執行,就有可能由於網路原因或者服務自身的問題導致呼叫故障或延遲,隨著服務的積壓,可能會導致服務崩潰。為了解決這一系列的問題

.NET Core服務基於Steeltoe使用Spring Cloud Config統一管理配置

一、關於Spring Cloud Config   在分散式系統中,每一個功能模組都能拆分成一個獨立的服務,一次請求的完成,可能會呼叫很多個服務協調來完成,為了方便服務配置檔案統一管理,更易於部署、維護,所以就需要分散式配置中心元件了,在Spring Cloud中,就有這麼一個分散式配置中心元件 —

.NET Core服務基於IdentityServer建立授權與驗證服務(續)

上一篇我們基於IdentityServer4建立了一個AuthorizationServer,並且繼承了QuickStartUI,能夠成功獲取Token了。這一篇我們瞭解下如何整合API Service和MVC Web Application。 一、整合API Service 1.1 新增ASP.NE