設定は、動的振る舞いを調整する能力を実行しています。
次の属性を設定します。
-
設定は、プログラムの独立した読み出し専用の変数であります
-
-
ライフサイクルを通じてアプリケーションを伴う設定
-
アプリケーションは、設定を読み込むことで、起動時に初期化し、実行時に設定に応じてその動作を変更します。
-
-
コンフィギュレーションモードをロードする方法
-
内蔵ハードディスクコードをプログラムし、このような行為がアンチパターンである、それは推奨されません。
-
プロフィール。
-
環境変数は、構成が読み取りプログラムが実行されている、オペレーティングシステムの環境変数にあらかじめ設定することができます。
-
プログラムの起動時の起動パラメータは、ワンタイムパラメータを提供することができます。
-
データベース、データベース上の変数の設定なので、実行時に設定を調整するための柔軟性に基づいています。
-
-
構成管理の必要性
-
アクセス制御：設定を変更する必要性は、そうでない場合は誤った構成は、災害を引き起こす可能性があり、優れたアクセス制御を持っています。
-
異なる環境、クラスタ構成管理：プログラムでは、多くの場合、異なる環境（開発、テスト、本番）、（異なるデータセンターなど）の異なるクラスターので、環境を改善する必要性、クラスタ構成管理で異なる設定が必要です。
-
コンポーネントの構成管理フレームワーククラス：CATはクライアントとして設定します。
-
第二に、なぜあなたは、中心を設定する必要があります
コンフィギュレーション・センターの導入がない場合には、一般的な研究開発するときは、次の痛みのポイントが存在します。
-
散在凹凸形状フォーマット
-
いくつかのxml形式で、だけでなく、DB保存いくつかの使用形式のプロパティ、YML形式でいくつかの、慣行が変化しました。
-
-
主に地元の静的な設定、設定変更のトラブル
-
分散型マイクロサービス環境では、サービスインスタンス際に多くの時間、時間のかかる構成の変更。
-
-
簡単に事故につながります
-
本番環境にテスト環境を設定した場合。
-
-
セキュリティ監査とバージョン管理の欠如を設定
-
何が変わっ見ることができない構成、および更新日時を変更するには、問題に加えて、バック時におけるロールバックすることはできません。
-
コア要件の中央の第三に、コンフィギュレーション
-
別の成果と設定
展開時の包装に使用される伝統的な慣行は、異なる環境用のパッケージ異なる構成を再生されます、各パケットは、特定の構成内の環境が含まれています。今お勧めの容器がパッケージ化され、マイクロミラーモードサービスを提供され、アプリケーションは一般的にミラーを果たし、あなたは異なる環境に展開することができますので、この構成では、搬送部材と分離部材のみ配信を行う必要があり、かつ不変ですあなたはどんな環境に配備することができます。設定環境が、すべてを一括構成の中心に配置することができ、アプリケーションの動作は、それぞれの環境に応じて配置された動的中心を引っ張るように構成されてもよいです。
-
抽象標準化
センターシールド構成の異なる形式は、ユーザーの構成管理は、自律的、構成管理および構成の詳細をカプセル化する必要があり、ユーザーは、通常の2つだけ抽象的関心と標準化されたインタフェースを必要とします：
-
構成管理インターフェースUI、簡単にアプリケーション開発者は、管理と構成を公開します。
-
クライアントAPIをカプセル化し、アプリケーションの統合を容易にするための設定を取得。
-
-
マルチマルチクラスタ環境
マイクロサービスアプリケーションは、彼らがマルチ環境の展開、環境開発/テスト/本番の一般的な標準を使用して、いくつかのアプリケーションはまた、マルチルーム、クロスバージョン展開のサポートなど、マルチクラスタ展開を、必要としています。コンフィギュレーション・センターは、マルチアプリケーション環境とマルチクラスタ構成のための集中管理をサポートするために必要な。
-
ハイアベイラビリティ
物流センターでは、それ以外の場合はマイクロサービスの大面積に影響を与えます、ハングアップすることはできません。
-
リアルタイム
コンフィギュレーションの更新は、このような青緑色のスタンバイスイッチの設定や展開の構成など、いくつかの設定の高いリアルタイム要件、クライアントにできるだけ早く通知する必要があり、これらの機能は、設定を切り替えるには数秒を要します。
-
コントロール
構成管理は、含む必要があります：
-
監査は、さかのぼることができます設定した後、あなたは、人を変え、コンテンツやイベント、簡単な問題を修正ログインする必要があります。
-
コンフィギュレーション・バージョン管理すべての変更は、バージョン管理を必要とし、問題が速やかに前のバージョンにロールバックすることができます。
-
アクセス制御の設定、構成の変更は、認証と承認を公開する必要があります。
-
グレーは、あなたが広告をするときは、何ら問題はアプリケーションの範囲を拡大することはできないことを確認してくださいいくつかの事例を反映させることができ、公開します。
-
第四に、アポロは何ですか
アポロは、異なる環境における管理アプリケーションを集中研究開発部門Ctripのフレームワークオープンソースの構成管理センタ、異なるクラスタ構成であり、構成の変更は、リアルタイムアプリケーション側にプッシュすることができ、アクセス許可、プロセス制御および他の機能を標準化しました。
アポロ次の特徴：
-
異なる環境の一元管理、異なるクラスタ構成。
-
アポロは、異なる構成を有することができ、集中異なる環境、異なるクラスタ、構成管理別の名前（名前空間）統一されたインタフェースの空間を提供し、異なるクラスタに同じコードを展開します。
-
-
即効性（放熱）との設定の変更
-
リリース管理
-
グレーリリース
-
クライアント構成情報の監視
-
あなたは簡単に構成例で使用されている画面上で見ることができます。
-
-
Javaと.NETネイティブクライアントを提供します
-
これは、オープンプラットフォームのAPIを提供します
-
シンプルな展開
あなたは、アポロは、ほぼ上記の物流センターのコアのニーズを満たす特徴、見ることができます。
第五に、アポロの基本モデル
-
ユーザーは、UIインターフェイス/解除の設定を変更することができます。
-
アポロ構成の更新情報配信センターは、クライアントアポロにプッシュされます。
-
その後、クライアントは、ローカル設定を更新した後、アポロの流通センターからアプリケーションへの通知を最新の構成を引っ張ります。
六、アポロクライアントの設計
1、アポロクライアントの実装原理
-
初めてプッシュ設定の更新を取得するように、クライアントとサーバは、長い接続を維持します。
-
プルするごとに5分はあなたがカバーに実行してapollo.refreshIntervalを指定することができ、デフォルトでは、クライアントは最新の構成アポロ物流センタープルアプリケーションサーバからの時間になりますが、クライアントタイムアウトプルは、ローカルバージョンに報告されます分インチ
-
クライアントは、アプリケーションの最新の設定にアポロフィギュレーションセンターサーバから取得した後、それがメモリに保存されます。
-
クライアントは、ローカル・リカバリの構成に応じて、ネットワーク障害やサービスの場合には利用できないことを保証するために、ローカルのファイルシステムキャッシュを設定するには、サーバーから引っ張ってくるだけでなく、高可用性をある程度達成します。
-
アプリケーションは、更新通知を設定するには、サブスクライブ、犯罪を構成するには、クライアントから取得します。
2、プッシュ設定のアップデートを実施
上述クライアントおよびサーバ上アポロ、それによって長い実際のHTTPロングポーリングを実施することによって接続されたプッシュ設定を得るために第1の時間を更新し、長い接続を維持します。
-
サーバーへのクライアントによって開始されたHTTPリクエスト
-
60代のためのサーバ接続
-
60年代で、クライアントの利益のために、構成変更があった場合、要求はすぐに戻り、クライアントが構成変更の名前空間の情報を持ってお知らせします、クライアントはそれに応じて、名前空間の最新の設定を引っ張ってきます。
-
60年代で、クライアントの利益のために変化がない場合は、HTTPステータスコード304は、クライアントに返されます。
-
サーバーでは、非同期サーブレット（春DeferredResult）サービスのHTTPロングポーリング要求に。
七、アポロ全体的なデザイン
脳卒中明確な思考する前に、そのうちの最初のは知っているモジュール：
主なモジュール：
-
ConfigService
-
インターフェイスコンフィギュレーションを提供して取得します
-
プッシュ・インタフェース設定を提供します
-
アポロは、クライアントにサービスを提供します
-
-
AdminService
-
構成管理インターフェースを提供します
-
提供配置修改发布接口
-
服务于管理界面Portal
-
-
Client
-
为应用获取配置，支持实时更新
-
通过MetaServer获取ConfigService的服务列表
-
使用客户端软负载SLB方式调用ConfigService
-
-
Portal
-
配置管理页面
-
通过MetaServer获取AdminService的服务列表
-
使用客户端软负载SLB方式调用AdminService
-
辅助模块：
-
Eureka
-
用于服务发现和注册
-
Config/AdminService注册实例并定期报心跳
-
和ConfigService一起部署
-
-
MetaServer
-
Portal通过域名访问MetaServer获取AdminService的地址列表
-
Client通过域名访问MetaServer获取ConfigService的地址列表
-
相当于Eureka Proxy
-
和ConfigService一起部署
-
-
NginxLB
-
和域名系统配合，协助Portal访问MetaServer获取AdminService的地址列表
-
和域名系统配合，协助Client访问MetaServer获取ConfigService的地址列表
-
和域名系统配置，协助用户访问Portal进行配置管理。
-
1、简化架构A
假设没有分布式微服务的服务发现，那么：
-
Portal会调用AdminService进行配置管理和发布
-
ConfigService和Client保持长连接，ConfigService服务于Client进行配置获取，ConfigService和Client通过一种推拉结合的方式，实现配置实时更新 的同时，保证配置更新不丢失。
-
ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息，而且这三者在每个配置环境（DEV/FAT/UAT/PRO)中都要部署一份。
-
Protal有个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Portal只需部署一份，它可以管理多套环境。
2、简化架构B
因为Client要找ConfigService需要地址列表，Portal找到AdminService也需要地址列表，这时候就需要服务发现了。
-
Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保持心跳。
-
Eureka采用集群方式部署，使用分布式 一致性协议保证每个势力的状态最终一致。
-
Client和Portal可以通过Eureka发现ConfigService和AdminService的地址列表。
3、简化结构C
因为携程需要跟自家的.Net的系统兼容，所以引入了MetaServer服务，这相当于是代理Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来。
但是MetaServer本身也是无状态以集群方式部署的，那么Client/Protal该如何发现MetaServer呢？传统的方式是借助硬件（可以在其中指定MetaServer的位置）或者是软件负载均衡器。
4、完全结构D
使用NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。