Web エンジニアとして、私はパフォーマンスとアーキテクチャに最も重点を置いていますが、幸いにも今回は sd2.0 カンファレンスに参加し、これら 2 つの側面について同僚と広範囲にコミュニケーションをとることができました。この記事は、このカンファレンスに参加して他の人たちとコミュニケーションをとった経験を友人たちと共有したものです。
建築設計についてのいくつかの考え:
1. 決して過剰なデザインをしない: 決して過剰なデザインをしない
これはよく言われるテーマですが、アーキテクチャ内でまったく使用されない、または最終的に放棄される機能がどれだけあるかを考えれば、最初にアーキテクチャ設計に携わるときにその重要性を理解できることがよくあります。 Huayi のアーキテクチャに関しては、非常に拡張性が高く、あらゆるニーズに適応できるインクリメンタルなアーキテクチャを設計したいと考えています。Web 開発の分野は、非常にダイナミックなプロセスを予測することが困難です。来週には変化が起こるため、できるだけ早く変化に対応することが最も効果的です。
eBay のエンジニアは、自社のアーキテクチャ設計がシステムの成長に対応できず、そのためシステムは常にひっくり返され、やり直しになっていると述べています。 eBay アーキテクトの能力には問題はありませんが、彼らが設計するアーキテクチャは常に古いバージョンのボトルネックの上に構築されており、新しいアーキテクチャがブレークスルーをもたらすことを期待しています。ただし、新しいアーキテクチャによってもたらされるブレークスルーは常に達成されます。短期間で新しい要求に圧倒されたため、新しいアーキテクチャを使用する必要がありました。
Web 開発は非常に機敏なプロセスであり、ユーザーのニーズは常に変化します。ソフトウェア開発と比較すると、将来のすべての設計を 1 つのアーキテクチャで計画することは非現実的です。
2. Web アーキテクチャのライフ サイクル: Web アーキテクチャのライフ サイクル
過剰なデザインを排除し、ある程度の先見性を確保する必要があるため、どのようにバランスを見つけることができるでしょうか。次の Web アーキテクチャのライフ サイクルが参考になれば幸いです。
設計されたアーキテクチャは、ハードウェア容量を増やすだけで 1 ～ 10 倍の増加に対応できる必要があります。5 ～ 10 倍の増加期間中に、次の 10 倍に耐えられるように、次のバージョンのアーキテクチャの設計を開始してください。二重成長
Google が優位に立つことができる理由は、検索技術や並べ替え技術が高度であるためだけではありません。実際、Baidu と Yahoo を含め、現在使用されている技術は類似しています。しかし、Google は社内に数万台のサーバーを追加することでこれを実現できます。十分なシステム容量を再現するのは確かに困難です。
3. キャッシュ: キャッシュ
キャッシュはコンピュータの設計において常に最優先事項であり、Web アーキテクチャの設計は重要であり、合理的なキャッシュを設計する方法については、創設者が述べています。 jbosscache タオバオの創設者は次のように述べています: 実際、Web キャッシュとエンタープライズ レベルのキャッシュの設計は大きく異なりますが、Web キャッシュはシンプルで高速です。 。
キャッシュによって引き起こされる問題は何ですか? データが複数のプロセスに分散されるため、実際のアプリケーションでは同期がさらに複雑になります。多くの場合、戦略はビジネスに結び付けられる必要がありますか?
Laoqian は Sohu が設計した投稿用のリンク リスト キャッシュを設計しました。これは柔軟な挿入のニーズを満たすだけでなく、他の大規模なコミュニティでも同様の構造を使用して投稿リストを最適化することがよくあります。道具
リンク: Qian Honwu のアーキテクチャ設計に関するビデオ http://211.100.26.82/CSDN_Live/140/qhw.flv
キャッシュの一般的な戦略は、時間のかかるディスクではなくメモリにデータを保持することです。この観点から見ると、MySQL が提供するヒープ エンジン (ストレージ方式) は、データをメモリに保存しつつ、SQL の強力なクエリ機能を維持できる一石二鳥の方法です。
ここでは読み取りキャッシュについてのみ説明しましたが、実際には、書き込みキャッシュもあります。これは、コンテンツ指向のコミュニティで解決する必要がある主な問題は読み取りの問題であるため、処理能力が低い場合にはほとんど使用されません。単一のリクエストがキャッシュされてブロックを形成し、その後バッチで処理される場合、書き込みキャッシュは、高度にインタラクティブなコミュニティ設計で簡単に見つけることができます。
4 番目に、コア モジュールは自分で開発する必要があります。コア モジュールを DIY します。
Qian Honwu と Yunfeng は、コア モジュールが関与していない場合でも、実際に使用する可能性があるため、注意を払う必要があると述べました。アクセス数が一定のレベルに達すると、これらのモジュールには何らかの問題が発生することがよくあります。もちろん、その問題の原因はオープンソース モジュールに不慣れであることにあると考えられますが、いずれにせよ、コアに問題がある場合は問題が発生します。コードを完全に理解していないと非常に怖いです。
5. 合理的なデータストレージ: 合理的なデータストレージ
必ずしもデータベースを使用する必要があるわけではありません。Lei Ming は、ゲームには必ずしもデータベースが必要ではないと言っています。では、なぜ単純にデータベースを使用すればよいのでしょうか?交換しますか？
まず第一に、データベースはファイルに対しても動作することを認める必要があります。主に次の機能を使用するためにデータベースが必要です。リレーショナル データベースでは、実際にはデータベースの複雑な検索機能が非常に重要です。じっくり読む必要はありません、ざっと見るだけで大丈夫です）
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(Reviewid=a.Id のレビューから count(Id) を選択) as countNum from Creativity as a、User_info as b、class as c、class2 as dここで、a.user_id=b.id、a.Creativity_Class=c.Id、および a.Creativity_Class_2=d.Id
Creativity を a、User_info を b として選択し、a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) を countNum として選択します。 、クラスを c、クラス 2 を d、レビューを e として、a.user_id=b.id および a.Creativity_Class=c.Id および a.Creativity_Class_2=d.Id および a.Id=e.Reviewid を a.Id でグループ化します。 ………………………………。