リストラがビジネスの離陸を助ける：年間成長率10倍の10億レベルのeコマースプラットフォームの技術ストーリー
序章
この記事では、累積 GMV が 100 億を超える e コマース プラットフォームが、年間パフォーマンスの 10 倍のハリケーン成長 (年間 GMV 5 億から年間 50 億) の下で、0 から 1 になる方法について説明します。リファクタリングの練習。
主なシェア:
- リファクタリングする理由
- リファクタリングはどのように開始され、実装されますか?
- 実際に遭遇した課題や落とし穴は何ですか?
一緒に交流し、議論し、学ぶことを歓迎します。
システム再構築後のコア指標データ
まずデータを見てみましょう.これは、リファクタリング後にシステムのコア指標で得られたビジネス結果データです:
1. システム パフォーマンスの向上、パフォーマンスの向上: プラットフォームは最大 500,000 人以上の同時オンライン ユーザーをサポートし、インスタント フラッシュ販売をサポートし、リンク システム全体のパフォーマンスは、月間 GMV から 50,000 QPS から最大 320,000 QPS に急速に改善されます。 1億+から10億+マーク突破。
2. システム アーキテクチャの変革、大砲のためのピストル: モノリシック アーキテクチャからマイクロ サービス アーキテクチャへの変革後、システム アーキテクチャの機能が大幅に改善され、技術チームは技術的負債を負うことがなくなり、技術的な問題がビジネス開発を妨げることもなくなりました。 .
3. 効率的な配送を実現するビジネスミドルプラットフォームの構築: 電子商取引の中核分野にビジネスミドルプラットフォームを構築することで、小さなフロントデスクと大きなミドルデスクのアーキテクチャシステムを実現し、ビジネスの効率的な配送能力を向上させます。機能。
4. オープンソースの技術的能力とオープンソース コミュニティへの還元: L2Cache と呼ばれる分散二次キャッシュ フレームワークを世界トップの IT オープンソース コミュニティに提供し、キャッシュ雪崩、キャッシュ侵入、ホットスポット キャッシュなどの問題の解決を支援しました。オープンソースにして、オープンソースに戻してください。これまでに、4 つのテクニカル オープン ソース プロジェクトがコントリビュートされました ( Github ウェアハウス アドレス)。
1. 背景
なぜリファクタリングを行うのですか？
2018 年から 2019 年にかけて、ビジネスの立ち上げ段階で、製品の実現可能性を迅速に検証するために、単一のアーキテクチャが技術的に選択され、製品の迅速な反復的な立ち上げの要求を満たすことができました。ビジネスの発展に伴い、さまざまな新しい機能がますます豊富になり、システムは大規模化、肥大化、複雑化しており、全身に影響を与えるコードがいたるところにあります。大きなプロモーションがあるときはいつでも、瞬間的なトラフィックがシステムに与える影響をかろうじて耐える唯一の方法は、さまざまなインフラストラクチャをアップグレードするためにお金を使うことです.
2020年の初め、流行の影響を受けた流行の初期に、オンラインショッピングの傾向はさらに加速し、Yunhuobaoのユーザー数と取引量は爆発的な成長を示しました。同時に、システムはますます厳しいテストに直面しています. システムは大きなプロモーションがあるたびにシャットダウンされ、アップグレードにお金を費やしても無駄です. 古いシステムの基盤となるアーキテクチャ設計は大きな影響を与えています.ビジネスの急速な発展。
生産および研究チームの規模が継続的に拡大するにつれて (チームの数は、ピーク時には 300 人近くに達しました)、コードの分岐と関数の開発が競合することが多いなど、複数人でのコラボレーションの効率性が現れ始めました。さらに、モノリシック アーキテクチャの問題点がますます明白になり、テクノロジーがビジネス成長の最大のボトルネックになっています。
リファクタリングはどのような問題を解決しますか?
リファクタリング前、当時のシステムが直面した状況には、主に次の点が含まれていました。
1.商品の配送効率が悪く、オンラインでのトラブルが多い: 商品の配送効率が悪く、遅延が発生しやすい。コード マージの競合、オンライン要件の待機、オンライン SQL の低速化などの問題がときどき発生し、「技術待ちのビジネス」という現象が時々発生します。オンラインになった後、技術的な「尻拭き」インシデントが頻繁に発生し、さまざまな製品機能のバグが引き続き発生しました。
2.チーム間のコラボレーション効率が低く、コミュニケーション コストが高い: 古い技術フレームワークと歴史的なアーキテクチャ設計の不十分さに制約されているため、現在、複数のチームのコラボレーションの下で効率的な方法で製品機能を提供するという要件を満たすことは困難です。
3.コードにパフォーマンス上の問題があり、システムが頻繁にダウンする: コードのビジネス ロジックの結合度が高いため、コードの保守性と可読性が非常に低くなります。ちょっとしたミスがシステム全体に致命的なダメージを与えたり、システムのパフォーマンスに大きなボトルネックが発生したりして、技術系学生の自信を大きく傷つけてしまいました。
4.技術的負債が重く、ますます蓄積: ビジネスの急速な成長に伴い、要件の反復速度が加速し、チーム メンバーも急速に拡大しています。しかし、過去の技術仕様、技術フレームワーク、システム アーキテクチャなどの歴史的な問題の影響により、チームは多額の技術的負債を蓄積しており、急速に変化する市場の要求に対応することが困難になっています。
上記のペイン ポイントは、モノリシック アーキテクチャ システムが特定の段階に発展した後に直面する典型的な問題であり、コア ブレークスルー ポイントでもあります。
これらの問題を解決するには？
上記の問題点を完全に解決するために、最終的に「リファクタリング」を選択しました。
ローカル最適化ではなくグローバル リファクタリングを選択する理由
当時、ビジネスは急速に成長しており、技術的な問題が絶えず発生していました。既存のシステムを単純に最適化するだけでは、問題を根本的に解決できないことがわかりました。したがって、私たちは難しい決断を下し、これらの問題点に対処するために「リファクタリング」を選択しました。
歴史の重荷を脇に置いて、新たなスタートを切ることを選んだのは、その時は最善の選択だと思いました。
次に、リファクタリングの実際のプロセスを詳しく紹介します。
2. システムリファクタリングの実践プロセス
当時、ビジネスは急速に成長していましたが、システムは頻繁にダウンしていました。決定が下され、「リファクタリング」が不可欠になった今、高速で止まらずに車がタイヤを交換するにはどうすればよいでしょうか?
ここでは、同様のリファクタリングのニーズを持つ学生、特にリファクタリングを担当する No. 1 の技術者を支援することを目的として、システム リファクタリングの実際的なプロセスを共有し、参考になるアイデアを提供したいと考えています。
以下では、各ステップについて詳しく説明します。
最初のステップ: チームを作る
リファクタリングのテクニカル リードを任命する
システムの再構築は非常に重要な作業であり、まず第一に、プロセス全体をリードし、指導する経験豊富で熟練した技術担当者が必要です。これが最初のステップであり、最も重要なステップです。
なぜ？システム再構築の関連事項はすべて彼が作成したためです。
どんな人を選べばいい？どのような技術を選択しますか? 何をするって？してはいけないことは何ですか？実行する方法？これらの決定によって、システム リファクタリングの方向性と成功率が決まります。
その際、組織再編の決定は、新しい部門（建築部門）を設立し、いくつかの新しい人員を採用することでした。機能的には、ビジネスデリバリー開発部門から分離されており、リファクタリングのみに焦点を当てています。
なぜ新しい部門を作るのですか？
1. 既存のチームでは、中規模および大規模の電子商取引システムの完全な再構築の経験を持つ人はほとんどいません。
2. 既存のチーム メンバーは古いシステムの多くの問題点を経験しているため、良心の呵責があり、大幅な変更を行うことはできませんが、新しい部門のメンバーには歴史的な負担はありません。
3. 機能の分離とフォーカスの後、リファクタリング要件はビジネス要件の優先度と競合せず、リファクタリング要件の優先度が遅れます。
ヒント: 私たちと同じシナリオに遭遇し、リファクタリングが不可欠な場合は、「リファクタリング チーム」を元のビジネス デリバリおよび開発チームから分離して、集中して集中することをお勧めします。
ステップ 2: 技術フレームワークと仕様を決定する
1. アーキテクチャの選択を決定する
「マイクロサービス アーキテクチャ」を選んだ理由は？
1. 高いスケーラビリティ: マイクロサービス アーキテクチャは、システム全体を複数の小さなサービスに分割します。各サービスは独立しており、システムの水平方向の拡張を容易にするために、個別に展開、拡張、および保守できます。
2. 信頼性とフォールト トレランスの向上: マイクロサービス アーキテクチャでは、サービスの障害はシステム全体には影響せず、サービスの機能にのみ影響します。したがって、特定のサービスに障害が発生しても、システム全体がクラッシュすることはなく、システムのリスクと損失が軽減されます。
3. より良いチーム コラボレーション: 各サービスを異なるチームで開発および保守できるため、チーム間の結合が減り、コラボレーションがより柔軟かつ効率的になります。
4. 柔軟性の向上: マイクロサービス アーキテクチャでは、ビジネス ニーズに応じていつでもサービスを追加、変更、または削除できるため、システムの柔軟性が向上します。
2. テクノロジー スタックとフレームワークを決定する
モノリシック アーキテクチャからマイクロサービス アーキテクチャにアップグレードするには、テクノロジーの選択が最初のステップであり、私たちが選んだのは Spring Cloud Alibaba です。
Spring Cloud アリババを選んだ理由は何ですか?
Spring Cloud Alibaba は、次の理由から、オープン ソースの Spring Cloud ベースのマイクロサービス ソリューションです。
1. 標準化された構造を持つ完全なマイクロサービス システム: サービスの登録と検出、負荷分散、構成センター、分散トランザクションなどを含みます。これらのコンポーネントは、安定した信頼性の高いマイクロサービス システムを迅速に構築できます。
2. 高いパフォーマンスと優れた安定性: Spring Cloud Alibaba の基盤となるテクノロジーは、Alibaba の Nacos サービス レジストリと Sentinel フロー制御コンポーネントを使用しており、これらのコンポーネントは優れたパフォーマンスと安定性を備え、大規模なマイクロサービス アプリケーション シナリオをサポートできます。
3. コミュニティの活動が活発な大規模なエコシステム: Spring Cloud Alibaba のエコシステムは非常に広範で、Spring Boot、Dubbo、RocketMQ など、一般的に使用される多くのオープン ソース コンポーネントが含まれます。これらのコンポーネントは、Spring Cloud Alibaba と緊密に統合して形成することができます。完全なマイクロサービス ソリューションです。
4. 簡単な統合と展開: Spring Cloud Alibaba は一連の便利なツールとプラグインを提供します。これらは既存の開発環境に簡単に統合でき、コンテナー化された展開と自動運用と保守をサポートし、開発と保守を迅速に実現できます。マイクロサービス。
要約すると、Spring Cloud Alibaba を選択すると、安定した信頼性の高いマイクロサービス システムをより迅速かつ便利に構築することができ、大規模なアプリケーション シナリオのニーズを満たすことができます。
3. 開発仕様の策定
技術のアップグレードの過程では、チーム全体が従う開発ガイドラインと標準である開発仕様の策定が必要な部分です。これにより、コードの品質、保守性、およびスケーラビリティが確保され、開発効率が向上し、保守コストが削減されます。
開発仕様を策定する際の主な内容は次のとおりです。
- コーディング仕様の定義: インターフェイス仕様、コード形式、命名規則、注釈要件、フレームワーク仕様、アーキテクチャ仕様などを含む
- コード レビュー プロセスの開発: コード レビューの頻度、参加者、レビュー コンテンツなどを含む。
- テスト要件の定義: テストの種類、テスト カバレッジ、テスト ツールなどを含む
- 文書要件の定義: 文書の種類、文書の内容、文書の形式などを含む
- バージョン管理プロセスの策定: ブランチ戦略、バージョン番号管理、提出情報フォーマット、コード マージ プロセスなどを含む。
- 展開プロセスの開発: 自動構築、自動展開などを含む
4. マイクロサービス フレームワークを迅速に実装する
マイクロサービス アーキテクチャを迅速に実装するために、MVP ビジネス シナリオ (検索製品シナリオ) を事前に通過し、全体のフレームワーク、技術仕様、単体テスト、統合テスト、受け入れテスト、インターフェイス コントラクト テスト、および新しい開発プロセスを統合しました。 DevOps All run through など。
ステップ 3: リファクタリングの範囲を決定する
リファクタリングの範囲を決定することは非常に重要であり、リファクタリングのプロセスでは、リファクタリングの複雑さと期間を含むリファクタリングの成功または失敗に直接影響します。
したがって、リファクタリングの範囲とは何か、リファクタリングの境界はどこにあるのかを慎重に検討する必要があります。
しかし、復興の最初の突破口として、最も挑戦的な「コアメインリンク」を選びました。
ここでいう「コアメインリンク」の主な機能としては、ログインページ、ECプラットフォームホームページ、商品一覧ページ、商品詳細ページ、クーポン利用処理、注文確認ページ、注文処理、決済処理、返金機能、ショッピングカートなどがあります。機能。
なぜ「Core Main Link」を選んだのですか？
- チームの自信の問題: 以前のリファクタリングの失敗による後退により、技術チームは新しいラウンドのリファクタリングに自信を失っています。
- ビジネス成長の最大のボトルネック: 急速なビジネス成長の過程で、頻繁なシステムのダウンタイムと技術的な問題が、ビジネス成長の最大のボトルネックになりました。
- リファクタリングの価値と意義: いくつかの小さな問題を最適化して改善するだけですが、いくつかの小さなブレークスルーは短期間で達成できますが、根本的なアーキテクチャ設計の問題については、この方法は大きな価値はありません.
最終的に、技術チームの自信と決意を示し、チームの士気を復活させるために、パフォーマンスのボトルネックが最大で、再構築が最も困難な「コア メイン リンク」を突破口として選択しました。
これは、ビジネスの成長におけるボトルネックの問題を解決するためだけでなく、チームの強さと決意を示し、勝利への信念を外の世界に伝えるためでもあります。
ステップ 4: 元のビジネス ロジックを整理する
元のビジネス ロジックを整理する必要があるのはなぜですか。
1. 各 e コマース プラットフォームの製品ビジネス ゲームプレイには独自の特徴があり、すべてのプラットフォームに適用できる同一のビジネス ロジックはありません。
2. 急成長する事業は、事業を中断することはもちろん、影響を受けることもありませんので、再構築後の業務プロセスの正確性を確保する必要があります。
3. この再構築の核心は、主に基盤となるアーキテクチャの再設計と構築にありますが、元のビジネス ロジックは変更されません。
したがって、新しいチームが正式にコードを書き始める前に、元のビジネス ロジックを整理して理解することは、非常に重要で重要かつ必要なステップです。
それを整理する方法は？
主にいくつかの実践的な経験ポイントを共有します。
1.ビジネスロジック理解の精度を高めるために、コア業務を2人で整理することをお勧めします
特定のビジネスの場合、開発者は特定のビジネスの詳細に焦点を当てて整理する必要があります。再構築の範囲を「コアメインリンク」と定めた上で、例えば【受注関連業務】の仕分けを2人、【商品関連業務】の仕分けを2人で担当。
なんで2人並べるの？名刺の正確さを保証します。
このような分業は、コーミングの効率を向上させるだけでなく、ビジネスロジックレベルの精度をより確実にするために偏差を修正することもできます。
2. チームがグローバルなビジネスの視点を持つように、製品の同級生をチームに参加させることをお勧めします
プロダクトマネージャーの責任は、ビジネス全体に焦点を当て、製品全体のビジネス概要を整理し、チームメンバーと迅速にコミュニケーションして、チームがビジネス全体を理解できるようにすることです。
製品の観点から、チームによって提供された結果がビジネスの期待を満たしていることを確認してください。
3. ビジネスロジックを整理するとき、古いコードを読む必要はありません
レガシー コードを見て、すべてのビジネス ロジックを理解する必要はありません。ビジネス シナリオが明確である限り、古いコードに縛られることなく、製品のビジネス ロジックに基づいて新しいコードを直接記述できます。
この方法は、歴史的なコードに導かれたり妨げられたりせず、歴史的な負担をより早く取り除くことができます。
ステップ 5: 新しいシステム アーキテクチャの設計
システム アーキテクチャの計画と設計
現状把握と今後の計画に基づき、「コアメインリンク」を以下のECの基本領域に分割し、その中で「ユーザードメイン、オーダードメイン、プロダクトドメイン」を今回の再構築のコア領域とする。範囲。
全体システム構成図の設計
ステップ 6: リファクタリングの目標を決定する
長期的なリファクタリングの目標を特定する
長期的な目標は、システムの再構築を通じてプラットフォーム全体のパフォーマンスと信頼性を向上させ、プラットフォームが来年のビジネス開発をサポートできるようにすることです。
短期的なリファクタリングの目標を特定する
長期目標を決めた後は、長期目標をベースラインとして、短期復興目標を策定し、事業計画を策定し、スモールステップで実行する必要があります。
短期的な目標は、システムのダウンタイムをなくし、ビジネスを中断させず、テクノロジーの遅れをなくすことです。
ステップ 7: リファクタリング計画を実装する
これはプロジェクト管理プロセスであり、インターネット上には多くの情報があるため、ここでは詳しく説明しません。
主にいくつかの実践的な経験ポイントを共有します。
1. 知っているべき人はみんな知っている？
これは最も重要なステップであり、問題のほとんどは、変更の範囲や時間のペースなど、この問題について関係者が知らない「誰かが知らない」ことに起因します。
ここでいう関係者とは、まず技術関係者、工程関係者、事業部門やユーザー関係者、会社経営者などです。
2. 頭の中でリハーサルをしましたか?
ほとんどすべての事故は準備不足に関係しており、事前に十分な計画を立てなかったり、一部のリンクが無視されたり、十分な時間が確保されなかったりすると、プロジェクト全体の進行が遅れる可能性が非常に高くなります。間違い。したがって、頭の中で計画プロセス全体を可能な限り実行してください。
たとえば、プロジェクトには明確なプロジェクト計画会議が必要です。この会議では、各ステップで何をすべきか、順序と担当者、主要なマイルストーン ノード、必要なリソースとサポート、異常な状況と計画がリストされます。
プロジェクトのリスク管理に関して、経験を要約するためのマントラを共有したいと思います。「統一された目標、特定の責任、および完全なコミットメント」、つまり、誰もが目標を明確に理解していますか? 各タスクには担当者がいますか? 各タスクについて、担当者は約束された完了時間を与えられていますか?
3. 事故が起きた場合の逃げ道はありますか?
何事も良い方向に行い、悪い方向に計画を立てるべきです。十分な準備を行う一方で、ロールバック計画などの予期しないイベントに対する計画も準備する必要があります。
3. リファクタリングの過程で陥った落とし穴
1. 発注プロセスのリファクタリングの過程で、ビジネス イテレーションに発注プロセスも含まれる場合、この時点でどのように対処しますか?
これは非常に重要な意思決定プロセスであり、さまざまな要因とトレードオフを考慮する必要があります。本質的に、それは優先順位の問題です。当時、システムダウンが頻発する緊急事態では、システムの再構築の方が明らかに重要でした。
そのため、リファクタリング プロセス中は、オーダー プロセスに関連するすべてのビジネス要件を停止して、リファクタリング作業を優先するという戦略を策定しました。
この戦略は一部のビジネス関係者のニーズに影響を与える可能性がありますが、システムの安定性と信頼性を確保し、その後のビジネス開発の基盤を築きます。
現時点での「遅さ」は、未来の「速さ」のためです。
2. テスト中に明らかになった過去の問題にどう対処するか?
歴史的な問題については、私たちの戦略は次のとおりです。将軍は急いでウサギを追いかけません。致命的な問題に加えて、残りの問題は通常、リファクタリング プロセス中に処理されません。
一方で、時間と人的資源は限られています。また、過去の問題をすべて処理した場合、リファクタリング作業は予定どおりに行われません。一方、オンラインシステムには歴史的な問題がすでに存在しており、致命的な結果をもたらしていないため、急いで対処する必要はありません。
したがって、リファクタリングのプロセスでは、リファクタリング自体に集中し、リファクタリングがスムーズに進行するように重要な問題に対処する必要があります。
3.オンラインプロセス中に新しいシステムにスムーズに切り替えるにはどうすればよいですか?
注意すべき重要な点がいくつかあります。
-
オンラインリハーサル: 正式リリースの前に、環境の準備、データの移行、システム構成などのすべてのステップを含む、いくつかのシミュレーション訓練が行われ、オンラインプロセスの円滑性と再現性が確保されます。
-
スイッチの設計: 稼働後、スイッチをリファクタリングして新しいシステムに切り替え、いつでも古いシステムに切り替える準備をします。
-
ロールバック設計: オンラインに移行する前に、オンラインで発生する可能性のある問題に対処するためのロールバック計画を準備します。オンラインになった直後に監視し、問題が見つかったらすぐにロールバック計画を実施して、システムの安定性を確保します。
-
監視とログ: オンラインに移行する前に、監視とログのシステムを準備して、オンラインの問題をタイムリーに発見して解決できるようにします。
-
冗長リソースの予約: オンラインにする前に、サーバー、帯域幅、データベース接続などの特定の冗長リソースを予約して、システムがオンラインになった後も高い並行性や異常な状況下でも正常に動作できるようにします。
4. リファクタリング経験のまとめ
チームの次元
私たちは、「正しい人を選び、正しいことを行い、正しいことを行う」という3つの要素の重要性を深く理解しています。
1. 適切な人を選ぶ、これが前提です
戦いに勝つためには、チームメンバーの能力だけでなく、メンバー間の協力と暗黙の了解が重要です。したがって、能力があり、協力的で、共通の目標を持っている人を選んでください。
例えば、建築部門の中核メンバーを選抜する際には、優れたスキルと豊富な経験、そして責任感と勤勉さを兼ね備えた人材を採用します。
2. 正しいことを行う、これが方向性です
適切な人でさえ、物事が正しくなければ、あなたが望む結果を達成することはできません. 間違った方向に一生懸命努力すると、目標からどんどん遠ざかってしまうからです。
たとえば、リファクタリングのブレークスルーを選択する場合、システム全体や小規模ビジネスのシナリオは選択しません。
3. 物事を正しく行う、これが方法であり結果である
働き方が間違っていれば、いい人を選んで正しいことをしても、目標は達成できません。
例えば、リファクタリングの範囲を決めるときは、1ステップで終わらせるのではなく、「小さなステップで実行する」という戦略を採用しています。
別の例を挙げれば、歴史問題を扱うとき、私たちは眉毛やひげをつかむのではなく、「将軍はウサギについていくことができない」という戦略を採用しています。
本質的に、これらの 3 つの要素は、誰が、何を、どの方法を選択するかという選択を行っています。したがって、この3つの要素は不可欠であり、1つでも欠けても何事も成し遂げることは困難です。
したがって、選択を行うときは、特別な注意を払う必要があります。選択は、両方を持つのではなく、集中することです.
選択を誤ると、あなたの努力は無駄になります。
技術的次元
システムの再構築とは、一連の再構築手法によって、システムを混沌から秩序へと変化させることです。
カオスとは複雑性が高いことを意味する
高度な複雑さの特徴は、理解するのが難しい、維持するのが難しい、失敗しやすいということです.ビジネスが繰り返されるにつれて、複雑さが増します. ソフトウェアの場合、複雑さは、ビジネスの複雑さと技術的な複雑さの 2 つの側面に分けることができます。特に両者が混在すると複雑性と開発難易度が増します。
では、建築設計を行う上で、どこが難しいのでしょうか。複雑さを制御することは困難です。
複雑さを解決することは困難ですが、複雑さは制御可能であり、制御されている限り、複雑さはひどいものではありません。そのため、事前にリファクタリングの範囲と境界を確認する必要があります。
複雑さを効果的に制御するには？
いくつかの設計原則を共有します。
- 分離設計: 明確な構造。関心の分離の原則に基づいて、ビジネス ロジックと技術的な実装を分離し、システム全体が明確な構造を持つようにします。
- 分割統治: スケールを制御します。巨大なシステムを複数の小さなコンポーネントに分割することで、問題空間内のきめの細かい問題をより効率的に解決できます。
- 抽象的なデザイン: 変化に敏感。変化に対処する最善の方法は、変化を制御可能な範囲内に制限することです.デザインパターンなどの抽象的な方法により、さまざまな次元と粒度の変化を分離できます. 変更が発生した場合、最小限の適応のみが必要です。
ソフトウェア開発のプロセスでは、不必要な技術的負債を回避し、システムの健全な反復を確実にするために時間内にリファクタリングするために、優れた設計と実装に注意を払う必要があります。
やっと
リファクタリングは単なる技術的な作業ではありません。
0 から 1 へのシステムの再構築は、技術アーキテクチャのアップグレードであるだけでなく、チーム組織の自己改造でもあります。
ドキュメンテーション
テクノロジーが突破し、パフォーマンスが10倍に跳ね上がる：10億レベルの電子商取引プラットフォームの再構築の秘密（記事はWeChatパブリックアカウントで最初に公開されました：Weige Technology Team）
推奨読書
- 【まとめ】私の建築設計12原則
- マイクロサービス アーキテクチャの実践 - 私の経験共有のまとめ 2019 (システム アーキテクト) アーキテクチャの進化プロセス - 情報フロー アーキテクチャから e コマース ミドル プラットフォーム アーキテクチャまで
- E コマース ミドル プラットフォームのアーキテクチャ図
- 【思考】中台って本当に知ってる？
シリーズ共有
-------------------------------------------------- ----
-------------------------------------------------- ----
私について(個人ドメイン名、私に関する詳細情報)
私のオープンソース プロジェクト コレクション Github
皆さんと一緒に学び、成長し、激励できることを楽しみにしています, O(∩_∩)O ありがとう
提案や学びたい知識があれば、私と話し合ったり交換したりできます
質問の交換へようこそ。個人的な QQ 469580884 を追加できます。
または、私のグループ番号 751925591を追加して、コミュニケーションの問題について一緒に話し合ってください
嘘について話さないで、ただ実行者になりなさい
話は安いです、コードを見せてください