インターネット金融における IT アーキテクチャの基本要件 | 「Linux はこう学ぶべき」
| ここ 2 年ほどで「インターネット金融」という言葉が非常に普及しましたが、金融業界の情報システムアーキテクチャというと、この言葉を抜きにしてその知名度は非常に低いように感じられます。では、この用語も他の概念と同様、ITメーカーやコンサルティング会社に「だまされている」のでしょうか？本当にありません。筆者は銀行に勤める多くの友人たちと交流してきたが、これまでかなりの国有銀行、株式会社銀行、商業銀行がインターネット金融事業に取り組んでいる、あるいはインターネット金融を重要な業務内容としている。したがって、ネット金融に関しては、ITベンダーやコンサルティングベンダーは「騙している」のではなく、協力しているだけだ。 |
ここ 2 年ほどで「インターネット金融」という言葉が非常に普及しましたが、金融業界の情報システムアーキテクチャというと、この言葉を抜きにしてその知名度は非常に低いように感じられます。では、この用語も他の概念と同様、ITメーカーやコンサルティング会社に「だまされている」のでしょうか？
本当にありません。筆者は銀行に勤める多くの友人たちと交流してきたが、これまでかなりの国有銀行、株式会社銀行、商業銀行がインターネット金融事業に取り組んでいる、あるいはインターネット金融を重要な業務内容としている。したがって、ネット金融に関しては、ITベンダーやコンサルティングベンダーは「騙している」のではなく、協力しているだけだ。
金融業界の本質とインターネット金融の必要性
すべての IT ベンダーの中で、金融業界は最も重要で最も価値のある伝統産業です。では、金融とは一体何なのか、考えたことはありますか?
それが金融の本質であり、仲介者としての役割を果たします。例: デビッドはサムと一緒に中古住宅を購入したいと考えています。プロセスは次のようになります: デビッドとサムが同意した後、デビッドは銀行振込で頭金を支払い、銀行に行って住宅ローンを申し込み、頭金を支払います。銀行に行き、銀行がローンを承認した後、預金をし、最後の支払いが完了し、ついに家が引き渡され、デビッドは毎月ローンを返済するために長銀に入りました。このプロセス全体において銀行が仲介となり、すべてが銀行に関係します（不動産仲介業者も不可欠です）。次に、問題を考えてみましょう。デビッドとサムがお互いによく知っており、相互信頼度が高く、デビッドが金持ちである場合、デビッドはサムに家の全額を現金で直接（または分割で、さらに利息も支払います）支払うでしょう。サムに）そうすれば、中間にあるリンクはすべてなくなり、銀行は存在しなくなります。これは金融中抜きと呼ばれます。「中抜き」とは一般に、取引を行う際にすべての仲介業者をスキップし、供給側と需要側の間で直接取引を行うことを指します。「金融中抜き」は「金融中抜き」とも呼ばれ、英語では「Financial Disintermediation」と言います。
金融仲介排除の問題において、インターネットは何をもたらしたのでしょうか? それは波を煽る役割を果たした。インターネットは資金の需要と供給の両方の検索プラットフォームを提供し、資金情報の仲介として機能し、資金調達取引は双方自身で完了します。さらに、インターネットによって提供されるサードパーティの支払いプラットフォームは、取引の両当事者に頭金、送金、支払いおよびその他の機能を提供します。最終的には仲介金融市場の形成を促進する。
その一方で、金融の中抜きが激化している一方で、2014年に同国が預金金利規制を自由化して以降、預金と融資のスプレッドに依存する銀行の伝統的な収益モデルは持続不可能であり、銀行の伝統的なモデルにおける競争は劣悪な状況に陥っている。紅海モデル: 銀行は収益性を高めるために、業態と革新的なビジネス モデルを早急に拡大する必要があります。
つまり、現在、銀行業界が直面しなければならないのは、同一業界内での同種競争だけでなく、インターネットによる国境を越えた競争でもあるのです。この場合、州がインターネット業界の金融セクターへの関与を禁止し、銀行を保護するために高い障壁を設ける行政命令を出さない限り、銀行が変更を加えなければ、実際、州の文書は次のとおりです。
したがって、現在の業界の観点から見ると、金融業界、特に銀行はインターネット金融サービスを精力的に開発する必要があります。
実際、銀行だけでなく、金融業界や保険業界にもインターネットによる攻撃が始まっています。現在、アリババはすでに保険を販売しており、Alipay クライアントを通じてそれを確認できます。
インターネット金融のビジネスモデル
次に、インターネット金融の主なビジネスモデルを見てみましょう。現在、銀行業界には主に 5 つのインターネット金融ビジネス モデルがあります。
- 第三者決済には主に銀行と第三者決済機関との連携が含まれます。最新ニュースは、CCBとAlipayが相互認識と相互スキャン協力を実現すること、ICBCとWeChat QRコードの相互認識と相互スキャンを実現することである。
- P2P ネットワーク ローンに関しては、資産管理や株式などを購入するためのオンライン バンキングなどがあります。
- ビッグデータファイナンス。銀行は、独自の内部データ分析を通じて、またはサードパーティ組織からのビッグデータの助けを借りて顧客の信用格付けを分析し、融資の迅速な承認とクレジット カードの限度額の迅速な引き上げを実現できます。
- 従来のサービスのインターネット化。児童返済サービスとは、モバイルバンキングのスマホアプリを通じて実現される理財商品、貴金属取引、公共料金の支払い等のサービスを指します。従来のサービスのインターネット化を実現するには、1. 銀行直販銀行業務 2. WeChat Bank、Alipay などとのドッキングの 3 つの方法があります。3. 振込決済やソーシャルチャットなどのサービス端末を提供します。
- インターネット金融ポータルの核となるのは「検索＋価格比較」です。Xingyeの「Qianda店主」、Rong 360など。
そう言えば、「ダイレクトバンキング」という概念も加わる。現在、多くの銀行が直販銀行業務を精力的に展開しており、直販銀行部門を独立して設置し、独立して上場している銀行もある。
ダイレクトバンキングは、インターネット時代の歴史的瞬間に誕生した新しいタイプの銀行運営モデルであり、インターネット金融技術（FINTECH）環境下での新しいタイプの金融商品です。このビジネスモデルでは、銀行は店舗を持たず、物理的なキャッシュカードも発行せず、顧客は主にコンピュータ、電子メール、携帯電話、電話などのリモートチャネルを通じて銀行商品やサービスを入手します。店舗運営費や管理費がかからないため、 、直販銀行は顧客に、より競争力のある預金およびローンの価格と、より低い手数料率を提供できます。営業コストの削減と顧客への還元は、ダイレクト バンキングの中核となる価値です。
Industrial Bank のダイレクト バンキング ページ (http://directbank.cib.com.cn/) を見てみましょう。
興業銀行の直販銀行は、知英宝、定期、資産管理、ファンド、工業宝などの豊富な投資・資産管理商品を顧客に提供しており、複数の銀行カードのオンライン直接購入をサポートしており、操作はワンクリックで簡単です購入。
江蘇銀行のダイレクト バンキングのモバイル クライアントを見てみましょう。
インターネット金融における IT アーキテクチャ
インターネット金融にはいくつかの特徴があります。それは、ユーザー数が不確実であるということです。アプリケーションの強力なパーソナライゼーションと高速なイテレーション。したがって、インターネット金融サービスには一般に、IT に対する 2 つの要件があります。それは、強力な弾力性とアプリケーションの起動時間の短縮です。
従来の物理マシン モードでは、弾性的な拡張を実現することはほとんど不可能です。仮想化環境では、弾力的な拡張を実現できますが、相対的に複雑になります。そして、弾性膨張にかかる時間は通常数十分です。弾性膨張の点では、コンテナには独自の利点があり、通常は第 2 レベルの膨張を実現します。Red Hat Openshift テクノロジーの助けを借りて、商業銀行はOpenshift を使用してダイレクト バンキング ビジネスを構築し、大規模な一括口座開設やプロモーション活動などの突然の大量需要シナリオに簡単に対応できます。
アプリケーションの迅速な配信の問題に関しては、技術的な観点から見ると、CI/CD によりアプリケーションの配信時間を大幅に短縮できます。Lenovo の社内 IT 部門はRed Hatの Openshift テクノロジーを使用して、アプリケーションの起動時間を 10 倍近く短縮しました。
具体的なコンテンツの参照:
Lenovo Group| Red Hat コンテナ ソリューションと成功事例| The Container Chronicle
CI/CD を実装する 2 つの方法
技術的には、現時点で CI/CD を実装する最良の方法は、コンテナに基づいて CI/CD を実装することです。Red Hat の Openshift など。詳細については、この公式アカウントの記事を参照してください: フル ファイアパワー | 継続的インテグレーション、継続的デリバリー | 一連の典型的なコンテナ アプリケーション シナリオを理解するための 5 分
Docker テクノロジーと kubernetes フレームワークに基づいて、Openshift は、ソフトウェア デファインド ネットワーク、ソフトウェア デファインド ストレージ、権限管理、エンタープライズ レベルのミラー ウェアハウス、統合エントリ ルーティング、継続的統合プロセス (s2i/jenkins)、および統合管理コンソールを提供します。などの機能を統合して、ソフトウェアのライフサイクル全体をカバーするソリューションを形成します。
しかし、いくつかの考慮事項により、顧客が当面はコンテナ クラウドを使いたくない場合、CI/CD を実装するのがより便利になるでしょうか? これは、Jenkins と Ansible Tower の助けを借りて実行できます。
Jenkins + Ansible Tower で CI/CD を実装
継続的インテグレーション (CI) ==> 継続的デリバリー (CD) ==> 継続的デプロイメント ==> Devops
コンテナを介して CI/CD を実装しないことを前提として、Ansible Tower と Jenkins を統合することで、コードのデプロイ効率を大幅に向上させることができます。
継続的インテグレーションの目的は、高品質の確保に基づいて、製品を迅速に反復できるようにすることです。その中心的な対策は、コードがバックボーンに統合される前に自動テストに合格する必要があることです。1 つのテスト ケースが失敗する限り、それを統合することはできません。
継続的デリバリー (継続的デリバリー) とは、レビューのために品質チームまたはユーザーにソフトウェアの新しいバージョンを頻繁に配信することを指します。レビューに合格すると、コードは運用に入ります。したがって、継続的デリバリー、継続的デリバリーとは、継続的インテグレーションによって生成されたソフトウェアのテストを自動化することです。
継続的統合フェーズでは、Jenkins は Ansible Tower を呼び出すことで、開発、テスト、本番環境、その他の環境にコードをデプロイできます。環境は、物理マシン、仮想マシン、さらにはクラウド上に存在する場合もあります。
それでは、CI/CD には Jenkins または Ansible しか使用できないのではないかと疑問に思う人もいるかもしれません。以下の表を参照してください。
