也 10 年前的一篇文章，针对《对.NET 系统架构改造的一点经验和教训》一文的技术要点看法。
【对.NET 系统架构改造的一点经验和教训】里面的几条对 CSDN 的改造的技术要点如下：
- データ層はSQL Serverデータベースとストアドプロシージャを放棄し、すべてLinuxプラットフォーム上のMy SQLデータベースに移行します。
- キャッシュは. NET自体が提供するキャッシュメカニズムに依存しなくなり、Linuxプラットフォーム上にデプロイされた分散型Redisに移行します。
- サービス間の呼び出しは、. NET独自のプロプライエタリなプロトコルを使用せず、Restful HTTP Web API呼び出しに置き換えます。
- 静的リソース要求はもはやIIS自身で処理させず、Linuxプラットフォーム上のNginxに分離して処理します。
- 読み取りが必要なファイルシステムは、Linuxプラットフォーム上の分散ファイルシステムにアクセスするように変更されます。
- NETコードをデプロイするWindowsサーバはLVSの背後に配置され、LVSをロードバランシングとフェイルオーバーに使用します。
1. データベースはSqlServerまたはMy SQLを使用する
Webアプリケーションとして、Webエンドは決してボトルネックではなく、ボトルネックは常にデータエンドにあります。通常のロジックによると、. NETはコンパイルされ、PHPはインタプリタであるため、. NETはPHPよりも高速です。しかし、多くのウェブサイトはPHPで動作します。主にPHPのソリューションがあります。
システムに問題があるのは言語の問題ではなく、アーキテクチャの問題、あるいはアーキテクトの問題です。Webサービスとして、ボトルネックはほとんどの場合データベースにあります。sqlserverデータベースのライセンスが高価であるという問題については、qinfoに行ってパブリックコメントを見つけることができ、asp.netとmysqlデータベースを使用しています。基本的にSqlServerとMy SQLは構造化データベースであり、開発者にとって大きな違いはありません。データベースのスケーラビリティは、1）データベースの読み書き分離、2）サービスの水平分割、3）大規模なテーブルの垂直分割です。残りは細部にあります。
2. 自己キャッシュか分散キャッシュか。
CSDNキャッシュはRedisに移行され、個人的にはこれは. net自体のキャッシュメカニズムの問題ではないと感じています。分散キャッシュを行う場合、MemcacheまたはRedisを使用しているかどうか、マシンの間にはマシンがあり、確かにWebサーバーキャッシュは高速ではありません。ビジネス量が小さい場合、Web自体のキャッシュメカニズムを置き換えるためにキャッシュサーバーを使用することは実際には費用対効果がありません。システムアクセスがある程度に達すると、独自のキャッシュメカニズムがシステムの要件を満たすことができず、キャッシュサーバに切り替える必要があります。もちろん、キャッシュサーバーとしてWindowsサーバーを使用する人はいないと思います。. NET、Java、PHPなど。memchace/Redisを使用する場合のパフォーマンスの違いはありますか？CSDNの最初の改訂はブログシステムであり、ブログパークのブログシステムはすべて1つであるべきですが、現在の修正と変更はもはやオリジナルのものではありません。しかし、CSDNブログの膨大なユーザー数が. net独自のキャッシュでどのように生き残ったかを考えるのは難しい。ブログパークCloud Roadの記事を見ると、ブログパークがmemcachedキャッシュを使用していることがわかります。
私の理解では、キャッシュとして、ユーザー数が小さいときはWeb独自のキャッシュメカニズムを使用することができますが、ある程度のオーダーに達すると、独自のキャッシュメカニズムが大量のデータキャッシュのニーズを満たすことができない場合は、分散キャッシュコンポーネントに切り替える必要があります。主な目的は、データをユーザーの近くに置くことです。現在、多くのインターネットサービスはmemcachedまたはクラスYesキーバリューデータベースを使用してすべてのデータをキャッシュに入れますが、mysqlのような構造化データベースはデータベースのバックアップとしてのみ使用され、キャッシュが無効になった場合にデータベースからデータを読み取ることができます。
3. システムプロトコルの選定
マイクロソフトは、独自のものにいくつかのプロトコルを追加するのが好きで、独自のソリューションのセットしか使用できません。マイクロソフト製品のフルスイートを選択するのは本当に便利ですが、マイクロソフト以外のものを使用する必要があるときは慎重になります。Webサービスは主にWebサービスまたはWCFを持つHTTPサービスです。Webサービスは、XML形式のオープン標準のセットであるプロトコルのセットです。
Webサービスは、追加の専用のサードパーティ製ソフトウェアやハードウェアを必要とせずに、異なるマシン上で動作する異なるアプリケーション間のデータ交換や統合を可能にする新しい技術です。Webサービス仕様で実装されたアプリケーションは、使用する言語、プラットフォーム、内部プロトコルに関係なく、データを交換できます。Webサービスは、特定のビジネス機能を実行できる自己記述的で自己完結的な利用可能なネットワークモジュールです。Webサービスは、従来の業界標準やXMLやHTTPなどの既存のテクノロジーに基づいているため、展開も簡単です。Webサービスはアプリケーションインターフェイスのコストを削減します。Webサービスは、企業全体、さらには複数の組織間のビジネスプロセス統合のための共通のメカニズムを提供します。
Webトランスポートでは、JSONはXML形式よりも短く、JSによってネイティブにサポートされる形式であり、サードパーティのサポートも多くあり、XMLよりもキャリアとしてJSONを選択する方が優れています。私にとってRESTfulはデータアクセスのスタイルです。URLリクエストをより明確にします。合意ではなく。そのため、Webシステムでは、APIとしてRESTfulスタイルのAPIやJSONを使用する傾向があります。すべてがマイクロソフト製品であれば、WCFマイクロソフト製品が最良の選択肢だと思います。
4. ファイルシステムの選択
Linuxにファイルサーバを置くことはweindowsよりも優れています。少なくともLinuxは様々なファイル断片を処理する必要はありません。まあ、ファイルサービスもプレイしたことがない、悪いコメント。
5. 静的リソース要求はIISまたは単独で行われる
IISは静的ファイルのみを扱うことができますが、.aspxファイルのような動的ファイルにアクセスすると、IISはaspnet_isapiにリクエストを処理し、結果をIISに返します。静的ファイルのとしては、はiisより优位である。静的ファイルを扱う場合、通常はJSファイルとCSSファイルをマージして圧縮し、画像サーバとして機能する1つ以上の別々のセカンドレベルドメインを作成することです。フロントエンドの待機時間を減らす。または、写真サービスを再撮影、七牛などに任せて処理します。少し前に研究して、RESTとフォームAPIのインターフェイスを提供し、過去と簡単に統合できます。また、独自の静的ファイルサーバよりも安価なCDNアクセラレーションを提供します。
6. 負荷のバランス..。
Webサーバが十分でない場合は、Webサーバに負荷分散を展開する必要がありますが、負荷分散を展開する方法はたくさんあります。私はこれを導入したことがありません。単一のWebサーバーがビジネスニーズをサポートできない場合、負荷分散が必要です。
まとめまとめまとめ
ですから、上記の6 点のうち、2点目を除いて、著者はシステムを十分に理解していないと思います。システムには問題があり、繰り返しは言語の問題ではなく、アーキテクチャの問題です。もちろん、これは個人的な考えであり、私が知っていることはすべて間違っている。
著者：何か。 出典：beixiu.net/