エンタープライズレベルのコンテナクラウドプラットフォームの実装と実践

IT 業界の発展と変化に伴い、IT アプリケーションの基盤となるサポートも、メインフレーム、ミニコンピュータ、PC サーバー、仮想化テクノロジから今日のコンテナ化へと進化してきました。アジャイル開発、継続的デプロイメント、多様化したテクノロジー スタックの継続的な反復に基づいて、従来の基盤アーキテクチャはますます複雑になり、運用および保守管理では対応できなくなってきています。運用保守担当者は次第に終わりのない「消火」運用保守モードに陥っていった。

コンテナ技術の出現により、これらすべてが根本的に変化しました。コンテナの効率的なオーケストレーションと管理は、コンテナの無限の栄光を実現するための前提条件です。長年の開発を経て、Kubernetes は業界の事実上の標準になりました。 Kubernetes をうまく活用してエンタープライズ開発を促進する方法は、多くの企業、特にスタートアップ企業にとって無視できない難しい問題となっています。

この記事では、Amazon EKS を使用してエンタープライズ レベルのコンテナ クラウド プラットフォームを構築する方法を紹介します。一連の実践的な操作を通じて、Amazon Web Services が企業にコンテナ化されたアプリケーションを効率的に導入および管理するのにどのように役立つかを直感的に理解できます。

1. 従来のアプリケーションアーキテクチャのコンテナ化への道

「伝統的」という言葉を聞くと、まず頭に浮かぶのは「後進的」で「保守的」ですが、現実には、従来のアプリケーションの大部分は、依然としてこれらの従来のアーキテクチャ上で問題なく動作しています。サービス対象のオブジェクトは、特定の要因により、システム全体のリソースに対する需要に大きな変化が生じることはなく、システム機能の反復的な開発に対する頻繁な要求も発生しません。

しかし、インターネット、ビッグデータ、AIなどの技術の発展により、あらゆる産業が情報化からインテリジェンス化への変革に取り組んでいます。変革プロセスにおいて、アプリケーション シナリオの増加と頻繁な反復開発により、「従来の」アーキテクチャはますます大規模になりました。その結果、運用・保守担当者は「火消し」に追われ、システムサービスはますます不安定になり、システムコストは制御不能にまで高騰しました。

これらの問題を根本的に、そして完全に解決するにはどうすればいいでしょうか?コンテナ化/マイクロサービスは、多くの企業が大きな期待を寄せている方向性です。

コンテナ化は本当に効果的でしょうか?

次の写真を例に挙げてみましょう。これは非常に一般的なアーキテクチャです。 Tomcat は複数のサーバーに展開され、リバース プロキシ ソフトウェア (Nginx) を使用して各 Tomcat にリクエストを均等に分散します。 11.11 のプロモーションにより、既存の 3 台の Tomcat を 10 台に拡張する必要がある場合、運用および保守担当者はどのようなタスクを完了する必要がありますか? (サーバーのハードウェアが準備できていることを前提とします)

従来のシステムを拡張する手順:

1. OSをインストールし、セキュリティと権限を設定する
2. IPを割り当ててインターネットに接続する
3. Tomcatをデプロイする
4. 上記の手順を7回繰り返します

容量拡張を 1 回行うだけでも、経験豊富な運用および保守担当者が数時間を費やして完了する必要があります。これを 100 ノードに拡張する場合、ワークロードは指数関数的に増加します。

コンテナ化されたシステムを拡張する手順:

この作業にコンテナ化技術を使用すれば、多くの人的資源を節約できます。

1. OSをインストールし、Kubernetesで管理する

2. 1つのコマンドで数秒で拡張が完了します

kubectl スケール rc tomcat --replicas= 10

3. 終了

単純な比較から、コンテナ化技術は、リソース割り当て、システムの安定性（自己修復）、運用保守管理の面で企業のコストと運用保守のプレッシャーを効果的に削減し、企業が技術的な俊敏性と進歩を維持できることがわかります。

2. コンテナ化されたアプリケーションのシナリオ

これまで、企業にとってのコンテナ化の価値について説明してきました。次に、コンテナ化に適したシナリオを分析していきます。

コンテナ化の重要な特徴は、軽量かつステートレスであることです。しかし、従来のエンタープライズ アプリケーション ソフトウェアは、多くのビジネス モジュールを搭載し、機能プロセスが複雑であるため、コンテナ化変換には適していません。どのような特定のアプリケーション シナリオがより適していますか?主に以下のシナリオが含まれます（もちろん、これらは一般的な状況のほんの一部です。軽量でステートレスな特性を満たすビジネスシナリオでは、コンテナ化技術を試すことができます）

2.1 アプリケーションのパッケージ化

2.2 マルチバージョンハイブリッド展開

2.3 アップグレードのロールバック

2.4 マルチテナントリソースの分離

2.5 内部開発環境

これまで、Docker に代表されるコンテナ化のさまざまな利点について説明してきましたが、実際の運用環境では、企業が Docker を通じてコン​​テナ化を実装するだけでは、高可用性、柔軟な拡張、高い同時実行性などのシナリオの要件を満たすことはできません。 Kubernetes の登場により、Docker を本番環境で大規模に使用できるようになりました。 Kubernetes は、アプリケーションの展開、計画、更新、保守のためのメカニズムを提供し、コンテナ化されたアプリケーションの展開と管理をよりシンプルかつ効率的にします。

Kubernetes の機能:

• 移植性: パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、マルチクラウドをサポート
• 拡張可能: モジュール式、プラグイン式、マウント可能、組み合わせ可能
• 自動化: 自動デプロイメント、自動再起動、自動レプリケーション、自動スケーリング/拡張

Kubernetes と Docker を組み合わせることで、エンタープライズ コンテナ化への道が容易になり、ビジネス ニーズをより迅速に満たすことができます。しかし、すべての物事には二面性があります。すべてのプロジェクトがコンテナ化に適しているわけではなく、変更によって未知の影響が生じる可能性があります。技術と生産を尊重することによってのみ、コンテナ化の道をより着実に歩むことができます。

Kubernetes は優れていますが、関連する技術的蓄積があまりない多くのスタートアップ企業や従来型企業にとって、Kubernetes の学習コストは高すぎます。企業は、高可用性、ネットワーク、コンピュータ ルーム、および基盤となるアーキテクチャのその他の側面で一連の問題に直面し、コンテナ化への道は困難に満ちています。

3. Amazon EKS は、企業がコンテナ化の変革を迅速に実現できるよう支援します

独自のコンテナ化されたプラットフォームを迅速かつ効率的に構築するにはどうすればよいでしょうか?以下の段落は、Amazon Cloud Technology 公式 Web サイトにおける Amazon EKS の紹介です。

Amazon EKS は、独自の Kubernetes コントロールプレーンやノードをインストール、運用、保守することなく、Amazon Web Services プラットフォーム上で Kubernetes を簡単に実行できるようにするマネージドサービスです。 Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するためのオープンソース システムです。

Amazon EKS は、高可用性を確保するために、複数のアベイラビリティーゾーンにわたって Kubernetes コントロールプレーンインスタンスを実行します。 Amazon EKS は、異常なコントロールプレーンインスタンスを自動的に検出して置き換え、それらのインスタンスに対して自動バージョンアップグレードとパッチ適用を提供します。

Amazon EKS は、次のような多くの AWS サービスと統合して、アプリケーションのスケーラビリティとセキュリティを提供します。

• コンテナイメージ用の Amazon ECR
• 負荷分散のためのElastic Load Balancing
• 認証のためのIAM
• 分離のための Amazon VPC

Amazon EKS はオープンソースの Kubernetes ソフトウェアの最新バージョンを実行するため、Kubernetes コミュニティの既存のプラグインとツールをすべて使用できます。 Amazon EKS で実行されるアプリケーションは、オンプレミスのデータセンターで実行されているか、パブリッククラウドで実行されているかに関係なく、あらゆる標準 Kubernetes 環境で実行されるアプリケーションと完全に互換性があります。つまり、コードを変更することなく、標準の Kubernetes アプリケーションを Amazon EKS に簡単に移行できます。

4. 理論と実践を組み合わせてコンテナ化をより直感的にする

いろいろな理論について話し合った後、実際に遊んでみましょう。以下では、Amazon EKS でのコンテナ化されたデプロイメントを段階的に実行するシナリオを設計し、各ステップの技術的な詳細を紹介します。

1) Nginxを使用して3つのページを作成します: web1、web2、web3

2) 3 つの Web ページは、Amazon EKS によってサービス グループとして管理されます。

3) http 経由でアクセスし、3 つの異なるページをポーリングして効果を確認します。

注: web1、web2、web3 は実際には 1 つのビジネスである必要があります。実験効果を示すために、投票効果は別のページに表示されます。

4.1 環境整備：

4.1.1. Amazon Web Servicesアカウントが必要です

4.1.2.アカウントのリソース制限をチェックして、IGW、VPC、EIP などが十分にあることを確認します。

4.1.3. Amazon cli (eksctl を含む) をインストールし、kubectl を設定します。

4.1.3. 1. Amazon CLI のインストール:

 curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
 awscliv2.zip を解凍します。
 sudo ./aws/インストール

インストール結果を確認する

$ aws --バージョン

インストール方法参考リンク:

https://docs.aws.amazon.com/zh_cn/cli/latest/userguide/cli-chap-install.html

4.1.3.2 kubectlを構成する

aws eks --region cn-northwest- 1 update-kubeconfig --name my-zhy-eks

公式設定方法リンク:

https://docs.amazonaws.cn/eks/latest/userguide/create-kubeconfig.html

4.2 Amazon EKS クラスターを作成する:

4.2.1 コマンドの作成

#コマンド、パラメータコメント

--node-type ワーカーノードタイプ

--nodes ワーカーノードの数

CLUSTER_NAME クラスター名

AWS_REGION cn-northwest-1: 寧夏リージョン; cn-north-1: 北京地域

~~~~~~~~~~~~コマンドの作成~~~~~~~~~~~·

 AWS_REGION=cn-northwest- 1
 AWS_DEFAULT_REGION=cn-northwest- 1
クラスター名=my-zhy-eks

 eksctl クラスターを作成します --name=${CLUSTER_NAME} --version 1.15 --nodes= 3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}

4.22 実行成功時の出力:

 ##################
 eksctl クラスターを作成します --name=${CLUSTER_NAME} --version 1.15 --nodes= 3 --node-type t3.medium --managed --alb-ingress-access --region=${AWS_REGION}
 [ℹ] eksctl バージョン0.32 。 0
 [ℹ] 地域 cn-northwest- 1を使用
[ℹ] 可用性ゾーンを [cn-northwest-1b cn-northwest-1c cn-northwest-1a] に設定
[ℹ] cn-northwest-1bのサブネット -パブリック: 192.168 。 0.0 / 19プライベート: 192.168 . 96.0 / 19
 [ℹ] cn-northwest-1cのサブネット -パブリック: 192.168 。 32.0 / 19プライベート: 192.168 . 128.0 / 19
 [ℹ] cn-northwest-1aのサブネット -パブリック: 192.168 。 64.0 / 19プライベート: 192.168 . 160.0 / 19
 [ℹ] Kubernetesバージョン1.15を使用
[ℹ] マネージドノードを使用して「cn-northwest-1」リージョンに EKS クラスター「my-zhy-eks」を作成しています
[ℹ] は、クラスター自体と初期管理ノードグループ用に2つの別々のCloudFormationスタックを作成します。
 [ℹ] 問題が発生した場合は、CloudFormation コンソールを確認するか、 「eksctl utils describe-stacks --region=cn-northwest-1 --cluster=my-zhy-eks」を試してください。
 [ℹ] 「cn-northwest-1」のクラスター「my-zhy-eks」では CloudWatch ログは有効になりません
[ℹ] 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (eg all)} --region=cn-northwest-1 --cluster=my-zhy-eks'で有効にできます
[ℹ] Kubernetes API エンドポイント アクセスは、「cn-northwest-1」のクラスター「my-zhy-eks」に対してデフォルトの {publicAccess= true 、 privateAccess= false } を使用します。
 [ℹ] 2 つの連続タスク: { クラスター コントロール プレーン「my-zhy-eks」を作成、 2 つの連続サブタスク: { タスクなし、管理対象ノードグループ「ng-e5146e45」を作成 } }
 [ℹ] クラスター スタック「eksctl-my-zhy-eks-cluster」を構築しています
[ℹ] スタック「eksctl-my-zhy-eks-cluster」をデプロイしています
[ℹ] 管理対象ノードグループ スタック「eksctl-my-zhy-eks-nodegroup-ng-e5146e45」を構築しています
[ℹ] スタック「eksctl-my-zhy-eks-nodegroup-ng-e5146e45」をデプロイしています
[ℹ] コントロールプレーンが使用可能になるまで待機しています...
 [✔] kubeconfig を「/root/.kube/config」として保存しました
[ℹ] タスクなし
[✔] 「my-zhy-eks」のすべての EKS クラスター リソースが作成されました
[ℹ] ノードグループ「ng-e5146e45」には3 つのノードがあります
[ℹ] ノード「ip-192-168-5-37.cn-northwest-1.compute.internal」が準備完了です
[ℹ] ノード「ip-192-168-58-97.cn-northwest-1.compute.internal」が準備完了です
[ℹ] ノード「ip-192-168-65-234.cn-northwest-1.compute.internal」が準備完了です
[ℹ] 「ng-e5146e45」で少なくとも3 つのノードが準備完了になるのを待機しています
[ℹ] ノードグループ「ng-e5146e45」には3 つのノードがあります
[ℹ] ノード「ip-192-168-5-37.cn-northwest-1.compute.internal」が準備完了です
[ℹ] ノード「ip-192-168-58-97.cn-northwest-1.compute.internal」が準備完了です
[ℹ] ノード「ip-192-168-65-234.cn-northwest-1.compute.internal」が準備完了です
[ℹ] kubectl コマンドは"/root/.kube/config"で動作するはずです。'kubectl get nodes' を試してください。
 [✔] 「cn-northwest-1」リージョンの EKS クラスター「my-zhy-eks」が準備完了
##############

4.2.3 Eksctl を実行した後、約 10 分間待つ必要があります。このモデルの手順は非常にシンプルですが、実際には、Amazon Web Services は cloudformation を呼び出してバックグラウンドで多くの作業を実行し、それを完了します。次の図は、cloudformation のスタック手順を示しています。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

4.2.4 Amazon EKS 完了、クラウドフォーメーションステータス

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4.2.5 ノードステータス情報の照会

# kubectl ノードを取得する
名前 ステータス 役割 年齢 バージョン
ip- 192 - 168 - 5 - 37 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f
 ip- 192 - 168 - 58 - 97 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f
 ip- 192 - 168 - 65 - 234 .cn-northwest- 1 .compute.internal Ready <なし> 11m v1. 15.12 -eks-31566f

4.2.6.クラスターノードを拡張する方法

以前、eksctl を使用して 3 ノードのクラスターを作成しました。業務の増加に伴い、容量を拡大したい場合はどうすればよいでしょうか?現在のクラスターを 10 ノードに拡張する具体的なコマンドは次のとおりです。

 NODE_GROUP=$(eksctl get nodegroup --cluster ${CLUSTER_NAME} --region=${AWS_REGION} -o json | jq -r '.[].Name' )
 eksctl scale nodegroup --cluster=${CLUSTER_NAME} --nodes= 10 --name=${NODE_GROUP} --region=${AWS_REGION}

結果を確認する

eksctl ノードグループを取得します --cluster ${CLUSTER_NAME} --region=${AWS_REGION}
 eksctl クラスターを取得する
名前 地域
my-zhy-eks cn-北西- 1

4.3. Amazon ECR の使用

企業の場合、多くの画像がカスタマイズされます。 Amazon Web Services ではカスタマイズされたプライベートイメージ管理はどのように実行されますか? Amazon ECR を使用するとイメージ管理が容易になります。次の手順では、httpd イメージを使用してプライベート httpdok イメージをカスタマイズおよび生成し、Amazon ECR にアップロードする方法を示します。

4.31.まず Amazon ECR リポジトリを作成し、それを選択して「プッシュ コマンドの表示」をクリックします。

画像出典: Amazon Web Services グローバル Web サイトのスクリーンショット

4.3.2. 「puhs コマンドの表示」の手順に従って、ローカルで作成したイメージを Amazon ECR にアップロードします。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

具体的なコマンド手順:

 # aws ecr get-login-password --region cn-northwest- 1 | docker login --username AWS --password-stdin <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn

ローカル画像を表示

# Docker イメージ
リポジトリ タグ イメージ ID 作成 サイズ
httpdok v1 df353399ffe4 7秒前 299MB

画像のタグ付け

# docker タグ httpdok:latest <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok:latest

ローカル Docker イメージを表示すると、ECR 接続文字列を含む新しいイメージが表示されていることがわかります。

 # Docker イメージ
リポジトリ タグ イメージ ID 作成 サイズ
<account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok 最新 9028c4373343 4分前 299MB
 httpdok 最新 9028c4373343 4分前 299MB

イメージをECRにプッシュする

# docker push <account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok:latest
プッシュはリポジトリ [<account_id>.dkr.ecr.cn-northwest- 1 .amazonaws.com.cn/httpdok] を参照します。

Amazon Web Services コンソールに戻ると、アップロードされた画像を確認できます。

画像出典: Amazon Web Servicesグローバル Web サイトのスクリーンショット

4.4 Amazon EKSインスタンスのデモ

Amazon EKS へのコンテナのデプロイを始めましょう。 Nginx を使用して、Amazon EKS にイメージをデプロイし、アクセスをポーリングする方法を説明します。

4.4.1. 3つのnginxポッドレプリカセットを起動する

YAMLファイルを準備する

cat <<EOF > nginx-deployment.yaml
 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: nginx-deployment
ラベル:
アプリ: nginx
仕様:
レプリカ: 3
セレクタ：
一致ラベル:
アプリ: nginx
テンプレート：
メタデータ:
ラベル:
アプリ: nginx
仕様:
コンテナ:
 - 名前: nginx
イメージ: nginx: 1.14 。 2
ポート:
 - コンテナポート: 80
終了

デプロイするには次のコマンドを実行します

kubectl を適用 -f nginx-deployment.yaml

作成ステータスを確認する

kubectl ポッドを取得 -o ワイド

4.4.2. LoadBalancerサービスを作成する

YAMLファイルを準備する

cat <<EOF > ロードバランサー.yaml
 APIバージョン: v1
種類: サービス
メタデータ:
名前: nginx-service
仕様:
タイプ: ロードバランサー
セレクタ：
アプリ: nginx
ポート:
 - プロトコル: TCP
ポート: 80
ターゲットポート: 80
終了

デプロイするには次のコマンドを実行します

kubectl 作成 -f ロードバランサー.yaml

作成ステータスを確認する

kubectl サービスを取得する
名前 タイプ クラスター IP 外部 IP ポート 年齢
nginx-service ロードバランサー10.100 。 212.244 ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn 80 : 31248 /TCP 7分53秒

ウェブページの表示を監視する

curl -silent ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn | grep タイトル
<title>nginx へようこそ!</title>

この時点で、EKS 上で Nginx クラスターの使用を開始しました。しかし、負荷バランスの作業効果を示唆するために。負荷分散の効果をよりよく観察するために、次の小さな実験を続けます。

4.5.投票効果の表示

4.5.1.ポッド情報を取得する

kubectl ポッドを取得する
名前 準備完了 ステータス 再起動 年齢
nginx-deployment-574b87c764-92jbs 1 / 1実行中0 10h
 nginx-deployment-574b87c764-hmz9t 1 / 1実行中0 10h
 nginx-deployment-574b87c764-nqpmc 1 / 1実行中0 10h

次のコマンドは、ポッド内のnginx welcomeインターフェースのindex.htmlの場所を決定します。

 kubectl exec -it nginx-deployment-574b87c764-92jbs -- /usr/sbin/nginx -t
 kubectl exec -it nginx-deployment-574b87c764-92jbs --cat /etc/nginx/nginx.conf を実行します。
 kubectl exec -it nginx-deployment-574b87c764-92jbs -- ls /usr/share/nginx/html
 kubectl exec -it nginx-deployment-574b87c764-92jbs --cat /usr/share/nginx/html/index.html を実行します。
 kubectl exec -it nginx-deployment-574b87c764-92jbs -- cp/usr/share/nginx/html/index.html /usr/share/nginx/html/index.html.bk

注: kubectl excel の形式は次のとおりです。

 kubectl exec -it <podName> -c <containerName> -n <namespace> -- シェルコマンド

4.5.3. index.html コンテンツを変更する

ファイル name.html をローカルで編集し、3 つの Pod のコンテナーにアップロードします。

kubectl cp name.html nginx-deployment-574b87c764-nqpmc:usr/share/nginx/html/index.html

注: ポッドとローカル間でファイルを転送するためのコマンド形式

ポッドはファイルをローカルにダウンロードします
kubectl cp -n ネームスペース名 POD名:Podファイル名 ローカルファイル名

ファイルをローカルのPodにアップロードする

kubectl cp ローカルファイル名 -n ネームスペース名 POD名:Podファイル名

最終的なクエリ出力結果、複数のクエリでは、ロードバランスによって接続がランダムに異なるポッドノードに割り当てられていることがわかります。

 curl -silent ae8e75d7e149044eb905b6bbff796e7e- 629951941 .cn-northwest- 1 .elb.amazonaws.com.cn | grep ノード

5. 結論

この記事を通じて、コンテナ化についての予備的な理解と、Amazon EKS 用に構築されたエンタープライズ コンテナ化プラットフォームについての予備的な理解が得られます。 Docker と Kubernetes は、エンタープライズ システムとビジネスの開発に欠かせない推進力を持っています。

しかし、Kubernetes の学習曲線と企業における Kubernetes の人材の蓄積には、どちらも長い「時間」コストが必要です。クラウド コンピューティング サプライヤーの成熟したプラットフォームと製品の助けを借りて、企業内での技術人材の蓄積コストを削減し、半分の労力で 2 倍の結果を達成できます。

この実践的な演習を通じて、Amazon EKS に基づくコンテナ化されたプラットフォームを作成するには、1 つのコマンドだけが必要であることがわかります。 Amazon EKS を使用すると、Kubernetes の作成、実行、保守が簡単かつ信頼性が高まります。 AWS Fargate を使用すると、企業は仮想マシン (EC2) を管理する必要性を完全に排除し、Kubernetes の最上位ビジネスアーキテクチャのロジックのみに集中できるようになります。これにより、基盤となるアーキテクチャのさまざまな問題に悩まされることなく、ビジネス開発に多くの時間を費やすことができます。また、これにより、運用および保守担当者は、終わりのない「消火」運用および保守モードから逃れることができます。

準備はできたか？コンテナ船が出航しました！さあ、一緒にさらなる可能性を探りましょう！

[[358188]]

参考資料:

https://docs.amazonaws.cn/eks/latest/userguide/what-is-eks.html

https://eksctl.io/usage/creating-and-managing-clusters/

https://github.com/liangruibut/EKS-Workshop-China

https://docs.amazonaws.cn/en_us/eks/latest/userguide/create-kubeconfig.html

https://amazonaws-china.com/cn/premiumsupport/knowledge-center/eks-kubernetes-services-cluster/

https://www.eksworkshop.com/beginner/130_exposing-service/ingress_controller_alb/

https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html

[編集者：張燕妮 TEL: (010) 68476606]