ゼロから数百億までのインターネット金融アーキテクチャの開発の歴史

振り返ってみると、会社の設立から最初のコード行が入力されてからほぼ 3 年が経ち、プラットフォームの技術アーキテクチャと技術システムも 4 回の大きなアップグレードと変革を経ました (現在、第 4 世代のアーキテクチャ システムが進行中です)。 ）、年末が近づいているので、私も時間をかけて、取引ゼロだった中小企業が取引量 100 億を超えるまで成長した中小企業の背後にある技術の変化を振り返りたいと思います。

概要

100億元を超えるインターネット金融業界では、実際には大きなプラットフォームではなく、実際には、アーキテクチャのアップグレードには大きなビジネスの進歩が伴います。前世代のシステムアーキテクチャは、事業開発の過程でいくつかの優れた開発事例が蓄積されており、次世代システムの開発においてはアーキテクチャのアップグレードが強力に推進されます。移行をスムーズに行える一方で、社内リソースが強力なサポートを提供できると同時に、技術パートナーは最先端のテクノロジーを使用して開発の達成感を得ることができます。 、約 9 か月に 1 回、システム アーキテクチャを現在の構造にアップグレードできます。

多くのネチズンは、プラットフォームの TPS はどれくらいですか、最大同時実行数はどれくらいですか、パフォーマンスはどうですか、とよく尋ねます。正直に言うと、私たちは小規模な会社であり、最も誇張されているのは、数万人が入札を競っているということです。同時に、中規模のインターネットとして、金融プラットフォームがしなければならないことは本当にたくさんあります。明確に言えるのは、これらのパラメータだけではありません。私たちはハイエンドのプラットフォームではありません。また、私たちが使用しているテクノロジーも、現在は比較的主流のオープンソース製品ですが、会社の継続的な開発の過程で多くの問題にも遭遇しました。そのため、より主流のオープンソース ソリューションを使用するよう最善を尽くしてきました。システム全体を構築するのに適しています。ここでは、プラットフォームの開発の背景にあるテクノロジーのアップグレードについて共有し、さらに多くの提案をしたいと考えています。

私たちはアーキテクチャに 4 つの大きな変更を加えました。各世代のアーキテクチャは次の一文に要約されています。

• 第 1 世代アーキテクチャの特徴: ビジネスが比較的集中しており、機能は投資および財務管理のニーズに対応し、迅速な立ち上げが可能です。

• 第 2 世代アーキテクチャの特徴: 分散システムの変革、プラットフォーム化の具体化、さまざまな垂直型ビジネス システムの構築と立ち上げ、ユーザー投資の大幅な充実、ビッグ データ プラットフォームの研究と活用

• 第 3 世代アーキテクチャの特徴。Zookeeper を登録センターとして使用し、dubbo を監視およびディスパッチング センターとして使用し、シングル サインオンを実現し、権限制御に hiro を使用します。

• 第 4 世代アーキテクチャの特徴: 第 4 世代アーキテクチャの技術サポートとして springboot+springcloud テクノロジを使用して、マイクロサービス開発モデルを完全に有効にします。

詳しい紹介は以下

第一世代のシステムアーキテクチャ

2014 年はインターネット金融元年と見なされるべきですが、これまで多くのインターネット企業が生き残るためにさまざまなモデルを使用していましたが、2014 年に最初に人気を博したのは Pingdaizhijia と Pingdao Tianyan でした。この種のサードパーティ Web サイトのトラフィックが突然増加し、その後、さまざまなインターネット金融会社が XXX ドルの投資を受けたという報道が増え、その方針が徐々に明らかになりました。私たちを含め、大企業（団体）もこのブームに乗じてフォローアップしてきました。

第一世代のシステムの主な目的は、時間を確保することであり、その時までにモバイルの波がすでに始まっていたため、同社はシステムの立ち上げを優先することにしました。モバイル版、Webサイトは当面検討できませんでした。当時、同社には PHP と Java という 2 つの開発言語の技術的余裕があり、PHP は迅速な開発に大きな利点を持っていたため、フロントエンド PHP + バックエンド Java のモデルを採用することにしました。システムは 3 つの層に分かれています: ユーザー層: Android および IOS モバイル端末; インターフェイス層: PHP がユーザー インターフェイスとトランザクション インターフェイスを提供します; バックエンド: バックエンドには、バックグラウンドとタイミング システムの 2 つの部分があります。バックエンドは PHP 開発とインターフェイス層を使用して 1 つのシステムを共有し、もう 1 つはタイミング システムであり、利息の計算、配当金の分配、期限切れおよびその他のスケジュールされたタスクを担当し、Java を使用して開発されます。

基本的なサービスとミドルウェアについては、mysql は最も基本的なマスター/スレーブ サポートを提供します。第一世代のシステムは mysql のメイン データベースのみを使用し、スレーブ データベースはユーザーの同時実行の問題を処理するためにのみ使用されます。入札、この部分のみが流通市場の転送マッチングやその他の非同期メッセージ通知に使用されます。プロジェクトのデプロイ: PHP は Apache を使用してデプロイされ、タイミング サービスはアプリケーション サーバーとして tomcat6 を使用し、フロントエンドの Apache ロードとして lvs が使用されます。基本的に、これらのテクノロジは第 1 世代のアーキテクチャ図です。システム。

初代システムの稼働後、特にWebサイトやH5（モバイルブラウザまたはWeChat）システムの構築が目立つようになった同社は、インターネット金融会社として公式Webサイトを持たないことに耐えられず、WebサイトやH5の開発に着手した。この期間中、PHP がこれまで行っていたバックエンドを取り出し、Java を使用して再計画されました。これまでのところ、PHP は Web サイト、APP インターフェイス、および H5 のコア トランザクションの 3 つのシステムを担当しています。 3 つのシステムでは、Java が管理およびタイミング サービスのバックエンドを担当します。このアーキテクチャを一般に 1.1 世代アーキテクチャと呼びます。

第 1.1 世代のシステム アーキテクチャ図、緑色の部分が変更された部分です

第一世代のシステムの欠点は、業務が集中しすぎ、立ち上げが急ぐこと、後期に多くの問題が発生することです。

第二世代のシステムアーキテクチャ

第 2 世代システムの背景には、企業の事業量の急速な発展に伴い、初期段階で負っていた多くの技術的負債が爆発的に増加し、最も深刻な問題は個人への配当の繰り返しでした。と色々と叱られたのは今でも記憶に新しいです。一方で、さまざまな事業部門からは常に需要があり、会社の製品も常に需要があるため、現段階では垂直型ビジネスシステムの開発と並行して、さまざまな生産上の問題の解決に追われています。初代のシステムはクローズドで開発していたので、復帰してからまた発売するのが大変で、本当に辛かったです。

最初にオンライン化された垂直サブシステムは契約システムでした。当時は、ユーザーが入札を行っても契約は成立しませんでした。多くのユーザーは非常に不安を抱えていました。その後、契約システムだけでも 3 つのバージョンに変更されました。最初のバージョンでは PDF のみが生成され、第 2 段階では電子署名が追加され、カスタマイズされて動的に生成された PDF が開発されました。ユーザー招待、投資およびその他の生産ポイントを現金クーポンなどと交換するために使用できます。メッセージ システムを抽出します。サイト メッセージ、テキスト メッセージ、電子メールなど。オンライン監視システム、ビジネス監視およびサービス監視、およびビジネスを開始します。失敗の早期警告、各事業部門は要求を高め、オンライン化を継続する 金融システム：財務スタッフが金額を計算し、販売のための販売システムを開発し、外部アクセスシステムを開発する。多くのサードパーティ システムを使用します。

第一世代のシステムは急いで構築され、製品のインターフェースはひどいものでした。その後、フロントエンド システムのニーズに応えて、Web サイト 2.0、APP2.0、H52.0 の計画が始まりました。プロジェクトや企業の発表、ニュースなどを公開するバックエンドのシステム。一般に、第 2 世代の製品側は、多くのビッグデータ分析のニーズを計画し、投資の優先順位と投資金額が完了した後、公式 Web サイトに表示されます。フロントエンドでは地図を使って表示するほか、個人向けの返済や収集したデータの分析など、大量のデータを実行する必要があるため、オフラインで処理できるように設計されています。計画中に、データは mysql スレーブ ライブラリから mongodb クラスターに同期され、mongdo の Mapreduce テクノロジーが大量のデータを処理するために使用されます。

MySQL は tungsten-relicator を使用して mongodb にリアルタイムで同期され、mysql サーバー側で監視エージェントを起動し、同時にサーバー側でも mysql の binlog ログを監視します。上の図に示すように、データが変更された後、サーバーがそれを解析して mongodb クラスターに挿入します。それを紹介する記事: ビッグ データの実践 - データ同期 tungsten-relicator (mysql ->mongo)、実際、このツールの使用は特に安定していませんが、幸いなことに、最初はそれほど多くのオプションはありませんでした。徐々に慣れてきたら安定してきました。

データ クリーニング システムの開発に golang を大胆に使用しました。当時使用していた golang のバージョンは 1.3 でしたが、幸いにも golang 言語自体をトレーニングすることができました。非常にシンプルで効率的ですが、N を踏んでしまいました。たくさんの落とし穴がありましたが、最終的には予定どおりに本番環境に投入しました。その後、beego フレームワークに基づいたバックエンドを開発するために golang を使用しました。その後、ビッグデータ分析システムは別の世代にアップグレードされ、UI ユーザー層は、activeMQ 送信を通じてユーザー データを収集し、最終的に mongodb に保存しました。データ、クリーンアップされた結果は、フロントエンド ビジネス システムで使用するために結果データベースに保存されました。その後、beego+echart を使用して新しいバージョンのデータ分析システムが構築されました。

ビッグデータシステムのアーキテクチャ図

バックエンド データベースへの負荷が増大し続けるため、バックエンド管理システムとビジネス システムはマスターとスレーブから分離され、バックエンド管理システムはキャッシュを追加し、独立したイメージ サーバーを開始しました。 nginx を使用して構築; 第 2 世代のシステム開発 その過程では、多くの活動がオンラインで開始され、会社の最も急速な成長段階でもありました。

第 2 世代のシステム アーキテクチャ図:

すぐに要約しましょう:
第二世代アーキテクチャは、さまざまなビジネスシステムを立ち上げ、マスターとスレーブを分離し、将来のより多くのデータ処理のための技術的基盤を提供するビッグデータプラットフォームを構築しました
短所: 各ビジネスシステムが分割されると、各プロジェクト間の呼び出しが複雑になります。多くのバックエンドシステムがあり、プラットフォームの動作監視を完了するために各システム間で操作を切り替える必要があります。

第 3 世代のシステム アーキテクチャ

第 2 世代システムの開発が完了した後、私たちには 3 つの厄介な問題が残されました。1 つ目は、ビジネス システムが増加し続けるにつれて、第 3 世代システムの初期にはシステム間の呼び出し関係が急激に増加したことです。多くの基本コンポーネントが追加されているため、この問題はさらに悪化しています。2 番目の問題は 1 番目の問題を補完するものであり、システム間の呼び出し関係が多すぎるため、サブシステムの 1 つを移動する場合は、その構成ファイルを変更する必要がある可能性があります。関連するシステムを削除してサービスを再起動します。多くの場合、1 つのシステムを更新するために他のシステムも受動的に更新する必要があり、問題が発生した場合の運用開始と切り替えが複雑になります。各サブシステムには独自のアカウント センターがあり、ビジネス スタッフは日々の業務を完了するために何度もログインする必要があるため、この問題はますます顕著になってきています。

そこで、調査とシステムの選択などを開始しました。解決すべき最初の課題は、SOA サービス ガバナンスを導入し、サービスの登録と検出を通じてシステム間のデカップリングを解決することでした。当時、私たちは多くの検討を行い、最終的にダボを選択したのは他に理由がありませんでした。多くの人が基本的な水を使って水の中を歩きました。 2番目の問題を解決するために、構成センターを導入しました。そのとき、360のQihoo360/QConf、Springのspring-cloud-config、Taobaoのdiamond、Baiduのdisconfを調査しました。長い間悩んだ結果、最終的にdisconfを選択しました。これは Spring Cloud に最適でしたが、ここから Spring-cloud と Spring-boot が第 4 世代のアーキテクチャ選択の基礎を築いていることに気づきました。 3 番目の問題を解決するのはアカウント センターです。アカウント センターは、シングル サインオンを実装するために cas を使用し、権限制御に hiro を使用し、ログイン後の権限リストなどのサーバー インターフェイスを提供するために dubbo を使用します。

変換後のアーキテクチャ図

これに基づいて、共通コンポーネントは文字クラス、日付クラス、暗号化クラスなどの共通の基本クラスを処理し、ファイル システムを処理するための fastDFS クラスターを構築し、独立して redis クラスターを構築しました。スケジュールされたスケジューリング システムを開発し、すべてのスケジュールされたタスクをスケジューリング システムに統合し、フロントエンド PHP がシステムの変換、マスター/スレーブの分離、静的最適化などを実行して、スケジューリング戦略をページに自動的に追加できるようになりました。

その後、同社はクラウドファンディング プラットフォームの構築を開始し、今回のシステムは完全に Java 言語で開発され、アプリ側はすべての第 1 レベルのページがネイティブで開発され、第 2 レベルのページはすべてネイティブで開発されました。このモデルでは、すべてのバックエンドがサービスに dubbo を使用します。最終的なアーキテクチャは次のとおりです。

図ではシステムの一部のみを示しており、代わりに他のサービスが使用されます。

第 3 世代システムでは、SOA サービス ガバナンスが導入され、統合されたアカウント センターと基本コンポーネントが導入されました。欠点は、開発環境がより複雑であることです。

第 4 世代のシステム アーキテクチャ

人々は常に不満を抱いており、テクノロジーは常に最高のアーキテクチャ システムを使用することを望んでいます。第 3 世代のシステム アーキテクチャの開発中に、私は Spring Cloud と Spring Boot について学びました。その後、その利便性をますます認識するようになりました。 Spring Boot は、開発が迅速であるという利点が非常に気に入っています。また、Spring クラウド システムは、マイクロサービスの概念が常に提案されています。一方、国は、P2P 企業に銀行への預金を厳しく要求し始めています。銀行の関連インターフェースを分析した結果、ルールに厳密に従うには、同時にシステムの大幅な変革が必要であることがわかりました。同社は規制要件を満たしており、Baitiao 関連製品も開発しています。これも大きなプロジェクトです。上記の 2 つの背景を活用して、銀行預金と Baitiao のプロジェクトに取り組みながら、マイクロサービスを本格的に採用することにしました。

なぜ dubbo を放棄して Spring Cloud を全面的に採用するのかというと、3 つの理由があります。 1. Dubbo は長年更新されておらず、Spring Cloud は常に更新およびアップグレードされています。 2. Dubbo は主にサービスの管理と監視を行います。クラウドはほぼすべてのマイクロサービスを考慮します。統合された構成センターやルーティング センターなど、あらゆる側面が必要です。3. Spring クラウドは非侵入的であり、他の Spring プロジェクトと完全に統合されているため、開発がより効率的になります。

Spring Boot + Spring Cloud を使用して変革を行うことを選択し、マイクロサービス テクノロジの選択が決まりました。結局のところ、新世代のシステム変革が同時に元のビジネスに影響を与えてはなりません。最も重要なことは、元のシステムが分散開発モデルに従って開発されているにもかかわらず、一部のシステムは古いシステムのため、依然としてデータベースを共有しており、各独立したサブシステムが独自の独立したライブラリ操作を必要とすることです。システムはサブシステム データを変更またはクエリする必要があり、サービス間インターフェイス呼び出しを通じてそれを取得する必要があります。したがって、新しく開発されたプロジェクトと変換が必要なプロジェクトから Springcloud プロジェクトを開始する予定であり、他のシステムは一時的にルーター モードを介して通信します。 最終的なシステム アーキテクチャ図は次のとおりです。

アーキテクチャの道に終着点はありません。アーキテクチャのアップグレードは、ビジネスをより良くサポートすることです。