構造調整
古いアーキテクチャ
の新しい構造
予備
クッキー、セッション
クッキーとセッションの違い
クッキーとセッションリンク
クロムEtherealのビュー// TODO
通常のシーンのログインセッションクッキーの下では、フローと組み合わせて使用
対称暗号化と非対称暗号化
付録2
- 対称暗号化
- AES、RSA次のような非対称暗号化、
- AES //参照aes.NewCipher（キー）関数アノテーションの使用
16,24,32ビット列なので、対応するAES-128、AES-192、 AES-256 暗号化方式
base64で//付録3
Q：関数の始まりbase64で
A：
- 実際には、本来の意図をコードするBASE64は、電子メールを直接満たすために非ASCII文字を指定することはできません使用することでした。
- すべてのバイナリファイルは、そのためのテキスト編集ソフトを使用して、印刷可能なテキストエンコーディングに変換することができ、およびデータストリームに簡単な暗号化されている。しかし、他の重要な意義があります。
Q：なぜ使用base64エンコード、需要シナリオ？
A：2つのシナリオがありますすることができません送信バイナリ
- 歴史的な理由電子メールの場合
- プレーンテキストプロトコルは、バイナリを送信することができない、base64エンコーディングを使用することができます。プレーンテキスト伝送プロトコルので、部分的に制御文字処理としてバイナリで起こり得ます。
サーバーの最適化のポイント
第10章クッキーの検証（単一ノード）を達成
- 改善されたポイントの
セッションアウトブレーク（代替セッションクッキー検証の実装） - アイデアは
：ユーザーは、クッキーの処理方法処理されたキー情報を析出、セッションを削除した
秘密鍵暗号を使用したuid：STEP1公開鍵暗号を。// 16ビットの秘密鍵暗号化結果128。
。STEP2 base64でエンコード：// HTTPはバイナリデータに保存することができないクッキーは唯一ascll文字を保存することができますので。 - 関連するコード
1. user_controller.go
登录接口的后端实现。本来登录成功后往只cookie写入了uid字段，为了防止uid被篡改，往cookie中写入了一个验证uid是否被篡改的sign字段。
2. auth.go
验证用户是否登录的中间件。验证uid是否存在。代码不变。第11章のパフォーマンスの最適化を実現するために、認証サーバを分散します
アーキテクチャを分散
機の過程で展開原則から、代わりに別のプロセスで複数のマシンに展開。
特権ベリファイヤ（水平展開）+コントロールの数（レベル拡張）Webサーバ+ + + MySQLのメッセージキュー：スプリット設定後
- アクセス権の検証：使用インターセプタを達成するために
- インターセプタ（伝達関数）付録4 //達成する//行くDecoratorパターン
機能：クッキーにユーザー情報を確認する（改ざんされていない）本物です。
アイデア：uidと符号の復号結果によっては、改ざんかどうかを確認するために、クッキーのマッチングを検証します。
コード：filter.go（ミアンパッケージ）+ validate.go单独部署。验证代码从代码中提取处理单独部署
拡張：のOAuthプロトコル
Q：なぜ、私たちはここに必要がある一貫性ハッシュアルゴリズム
A：メインのアプリケーションシナリオ一貫したハッシュアルゴリズムは、分散ストレージ、分散キャッシュ、ロード・バランシングです。ここでは、この種のアプリケーションキャッシュ我々はRedisのを使用していないことに注意を分散属しますが、メモリキャッシュと、各マシンが異なるユーザ情報キャッシュを格納します。
データストレージ要件：各マシン（プロセス）と格納されたUID要求時間。例UID = 1,2,3キャッシュ機1は、UID = 4,5,6バッファ2機で、次いでマシンは、キャッシュ・マシン上（ネットワーク内の）データを取得するために、2 1 = UIDを要求する1- 一貫性ハッシュアルゴリズム//付録5
Q：一貫性のハッシュアルゴリズムの主要な役割
A：一貫したハッシングは、スケーラブルなノードの問題を解決することです。
- ノードの追加および削除は、アバランシェキャッシュ（同時にキャッシュ同時故障の多数）を生成する通常のハッシュアルゴリズム。
- ノードと隣接する古いノードの追加と削除の間の領域に縮小、キャッシュミスの場合、アルゴリズムの整合性ハッシュ、。
- ハッシュアルゴリズムのコードは一貫性/ / TODOを達成するための
キーポイントを：
- IP =ローカルIPは、ユニットがキャッシュに読み込まれます。それ以外の場合はIP！=ローカルIP、その後、マシンがデータを取得するために別のマシンへのプロキシとして動作します。（ネットワーク伝送）
- キー構造
//创建结构体保存一致性hash信息
type Consistent struct {
//hash环，key为哈希值，值存放节点的信息 // TODO k: 请求key或节点的hash值 v: 真实节点或虚拟节点信息(如果有2个真实节点,每个节点20个虚拟节点,那么一共有20个v需要存储,环上其他位置并不需要存放数据)
circle map[uint32]string
//已经排序的节点hash切片 // TODO 排好序的虚拟节点hash值，40个元素，对应2个v。
sortedHashes units
//虚拟节点个数，用来增加hash的平衡性
VirtualNode int
//map 读写锁
sync.RWMutex
}- ハッシュアルゴリズムのアプリケーションでValidate.goの一貫性
//设置集群地址，最好内网IP
var hostArray = []string{"192.168.0.1", "192.168.0.2"}
var localHost = "192.168.0.1"
// 创建Consistent结构体
hashConsistent = common.NewConsistent()
// 添加服务器节点
for _, v := range hostArray {
hashConsistent.Add(v)
}
// 作为缓存的结构体
type AccessControl struct {
//用来存放用户想要存放的信息
sourcesArray map[int]interface{}
sync.RWMutex
}- 一貫性のハッシュアルゴリズムを使用してプロセスを使用します
- 異なるクラウドECSのロードバランスサーバーへのSLBの責任アリ雲は
、要求を処理するために、ECSのランダムな選択です。
第12章サーバーのパフォーマンス最適化ソリューションの売られ過ぎ＆紹介メッセージキュー
WRK
WRKと出力パラメータ変更
fronted/web/controllers/product_controller.GetOrder方法
データの元のメソッドのは大きな圧力にアクセスする、あなたが作成するたび順序は、データベースにアクセスするために複数回呼び出します。
新しい方法：- RabbitMQの消費モードの設定
- フロー制御によるメッセージ：メッセージのみ消費者に送信されるたび。設定項目：
channel.Qos - 確認モード：channel.Consume（AUTOACK：偽）
関連rabbimqコード実装
product_controller.go：次のメッセージGetOrder生産に単一のインターフェイス（）（メッセージ構造のための2つのフィールドを有する：[商品のuserId +）を
consumer.go：メッセージコンシューマ、フロー制御（1がメッセージを取る）、手動受信確認あなたが削除するとメッセージ（msg.Ack（false）を呼び出して、消費者の成功は、RabbitMQのメッセージ// TODO消費が失敗に対処する方法である必要があります削除）現在のコードで問題
のトランザクションなし（数量マイナス1+注文を生成します）
参照
- 対称暗号化、非対称暗号化、RSA（概要）
- 対称暗号化と非対称暗号化バインディングの例：HTTPS
- なぜ使用Base64でエンコードの原理とその実現
- あなたはデコレータ自然既存の機能をラップし、先頭またはの最後に、独自のカスタム機能を追加することができます
拡張：デコレータは絶対にRESTのAPIの保護に対処するための正しい方法はありませんが、私はあなたがのOAuth2 JWTを使用するか、この目標を達成することをお勧めします！OAuth2.0プロトコル
の拡張機能：次のようにオリジナルのGoウェブミドルウェアフレームワークが実装されている参照 - インタビューエッセンシャル：一貫性のハッシュアルゴリズムとは何ですか？
拡張：RedisのとMySQLは、二重書き込み整合性プログラムの決意