https://zhuanlan.zhihu.com/p/596978442
Showing posts with label Web. Show all posts
Showing posts with label Web. Show all posts
Sunday, October 1, 2023
Monday, September 18, 2023
[Web] Cache
Cache 的目的
彌補 Database 在複雜業務下的不足，基本原理是將可重使用的資料存放到記憶體中，這樣可以避免每一次都去 Database 讀取，進而將地效能。而以 Memcache 為例，查詢可達到 TPS 50,000 以上。雖然說增加 Cache 可以減輕 Database 的壓力，但會讓系統變得複雜，因此若 Cache 沒有設計好，則有可能造成系統崩潰
Cache 的應用場景
1 需要經過複雜計算才能得到值：每一次從 MySQL 去 Count(*) 大量數據，則不管怎麼優化 MySQL 都無法解決這個問題
2. 讀多寫少的資料：在 Social media 上，寫的人少（insert）但讀的人多（select），即使 Database 有下 index，但每一個人都去 select 也會大幅降低效能
快取 (Cache) 設計模式
快取 (Cache) 可能的問題
1. Cache penetration
Cache 並無作用，因此系統依舊還是要去找 Database ，具體可分為以下兩種情境
1.1 Database 本來就沒有這筆資料：照理來說這樣發生的請求量應該不大，但如果被惡意攻擊，有可能拖慢整個系統，解法可以是：
當搜尋的 Key 重複率較高時：把相對應個 Key 值給一個 default，這樣下次再被存取時就回傳空值。
當搜尋的 Key 重複率較低時：利用 Bloom filter（類似 hbase 判斷 key 否存在），若存在則去 Cache 或 Database 拿，反之則 return null。
1.2 緩存資料需耗費大量資源與時間：沒辦法把所有商品全部存到 Cache 裡，因此會需要分頁存，因此有可能在訪問時 Cache 會失效，進而 Cache 無法起到作用。
2. Cache avalanche
若 Key 全部都設同一個 Expire time，則當時間到會同時全部失效，此時會全部像 Database 索取資料，Database 會瞬間壓力過大，解決方法是利用一定區間的隨機值當來當作 Expire time。
3. Cache breakdown
Cache 失效後引起系統效能急遽下降的情況。例如當 key 值過期後，需要重新和 Database 拿資料，但是在拿資料的過程需要時間，若此時同時有大量訪問需求進來，全部都去 Database 拿資料就會造成問題，因此解法有兩種：
更新鎖：保證只有一個線程可以去更新緩存，其他線程則等待，不過當採分布式集群系統時，多個機器間也會產生緩存雪崩的問題，因此需要用到分布式鎖：Zookeeper
後台更新：由後台線程來更新緩存而非業務線程，具體會將 key 的期限設為永久，並且由後台線程定期清掃。但是當 cache 滿了時就會遇到問題，可能解法為：業務 thread 發現 cache 失效後，通過 message queue 發送一條消息通知後台 thread 更新 cache；或者後台 thread 依據對業務的了解，對於 Key 做定期清洗。
4. Hotspot cache
雖然 Cache 系統本身的性能比較高，但對於一些特別熱點的數據，如果大部分甚至所有的業務請求都命中同一份 Cache 數據，則這份數據所在的 Cache server 的壓力也很大，解決方法是，複製多份 Cache 副本到多個 Cache server ，減輕 Hotspot cache 導致的單台 Cache server 壓力。
注意：不同的 Cache 副本不要設置統一的過期時間，不然同時失效後可能引發 Cache avalanche。
From:
https://www.explainthis.io/zh-hant/swe/cache-mechanism
https://blog.toright.com/posts/3414/%E5%88%9D%E6%8E%A2-http-1-1-cache-%E6%A9%9F%E5%88%B6.html
[Web] Nginx
Nginx 是一個非同步框架的網頁伺服器，可以做到
1. http catch
2. 負載平衡
3. 反向代理
https://www.explainthis.io/zh-hant/swe/why-nginx
[微服務] RESTful API Design
Tool: https://reqbin.com/post-online
是一種風格，他描述了如何實現 Web API 的架構，基於 HTTP 協定，用來建立分散式系統，並支援多種程式語言，他的優點包含：
可擴展性：由於系統無需保留 Client 狀態，因此可以提高擴展效能。
靈活性：由於 Client 與 Server 完全分離，因此分層的應用程式功能可以提供靈活性。
獨立性：可以使用各種程式語言來編寫程式，不影響 API 的設計。
可以快取 Cacheable
Reference:
https://ithelp.ithome.com.tw/users/20130079/ironman/4342
https://javascript.info/fetch-crossorigin
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/CORS
https://www.shubo.io/what-is-cors/
https://pjchender.dev/webdev/web-cors/
https://miahsuwork.medium.com/%E7%AC%AC%E5%85%AD%E9%80%B1-api-%E5%9F%BA%E7%A4%8E-json-restful-curl-%E6%8C%87%E4%BB%A4-28670813764e
https://blog.huli.tw/2021/02/19/cors-guide-1/
https://ithelp.ithome.com.tw/articles/10267360
Saturday, August 12, 2023
[Web] load balance
負載均衡是企業應用基礎架構中的最重要的一部分。選擇合適的負載均衡可以提高應用可用性，安全性，性能等眾多好處。
現代化的軟件是負載均衡已經可以幫助我們支持基於DNS，HTTP/HTTPs，VIP（虛擬IP）等多種策略的負載均衡。而且強大的負載均衡還可以幫助我們實現網站訪問加速，TLS offload，cache，DDOS 等眾多高階功能。使我們後台的程序變的更加易於實現和管理
load balance 主要組成：
規測演算法
hartbeat
分為硬體和軟體：
硬體：F5
軟體：HAProxy、Nginx、LVS
分為三大類：
DNS Load Balancer (DLB)
Application Load Balancer (ALB)
1. Nginx
2. HAProxy
Network Load Balancer (NLB)
DNS Load Balancer (DLB)：第一層用於平衡不同的區域請求數量
將 request 分發到不同的 ip
Application Load Balancer (ALB)：針對用於 http或 https請求一種負載平衡
client -> http/https
透過 TLS termination proxy 解決
client -> encrypted -> ALB (證書管理) -> unencrypted -> App1
/image -> App1 server
.user-> App2 server
Network Load Balancer (NLB)
使用時機：性能要求較高的服務應用
優點：性能比較好
缺點。路由轉發路徑不靈活 (ip' port)
Reference
Sunday, June 25, 2023
服務發現
什麼是服務發現
當你在瀏覽器輸入 domain name，獲取網站服務的流程。
這流程中，DNS 會根據域名解析出 1 個 ip 位址，返回ip地址中對應鏈接包含的內容。我們根據特定的標誌（域名）來獲取我們所需要的服務，這就是服務發現。
而在微服務的領域，我們將應用拆分成一個個的微服務之後，服務發現，則變成了微服務之間相互獲取彼此的信息。
在微服務的場景下，使用DNS服務器作為服務發現的實現者會存在以下幾個問題
1. DNS服務器不支持動態變更，不能夠隨著服務的狀態變更（上線、下線、故障）而對域名映射變更
2. DNS只能支持域名和ip地址的一一映射，但在微服務的場景中，很多微服務都會部署多個實例，這也就要求標誌與服務要有一對多的映射
3. DNS服務無法解決多數據中心的問題
服務發現模式
服務發現主要存在有兩種模式，客戶端模式與服務端模式，兩者的本質區別在於，客戶端是否保存服務列表信息
https://blog.csdn.net/u013035373/article/details/79414529
目前成熟的服務發現應用
Reference:
https://blog.csdn.net/Mr_SeaTurtle_/article/details/77618403?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-4-77618403-blog-112297667.235^v38^pc_relevant_sort_base2&spm=1001.2101.3001.4242.3&utm_relevant_index=7
BFF
BFF 只是一种逻辑分层
BFF 解决了什么问题
同时为了保障 Android，iOS，以及 Web 端的不同需求，需要为不同的平台写不同的 API 接口，而每当值发生一些变化时，需要 Android，iOS，Web 做出修改。与此同时，当我们需要对一个字符串进行处理，如限定 140 个字符的时候，我们需要在每一个客户端（Android，iOS，Web）分别实现一遍，这样的代价显然相当大
而当我们有了 BFF 这一层时，我们就不需要考虑系统后端的迁移。后端发生的变化都可以在BFF 层做一些响应的修改。
例如，我们加入 BFF 层，原本每次访问发送 3 请求页面，变成一个请求。
Components of an event-driven BFF on AWS
Friday, June 23, 2023
微服務
* 墨菲定律 Murphy’s law
只要有可能出錯，就一定會出錯
* 高德納定律 Knuth’s law
在時機未到前優化是萬惡之源
* 諾斯定律 North’s law
每一個決定都是一次取捨
* 康威定律 Conway’s law
組織本身的溝通結構會反映在該組織所設計的系統上
* 帕金森瑣事定律 Parkinson’s law of triviality
組織成員會投入不成比例的心力在瑣事上
Microservices 是近幾年來軟體工程領域裡滿常聽到的熱門關鍵字之一。大概是在 SOA 出現後幾年開始崛起，跟 SOA 其實有 87% 像，所以最一開始 microservices 出現的時候，都還是被與 SOA 一同稱呼。兩者想要做的都是將一個單體式架構（Monolithic Architecture）依照功能拆成小塊，達到更好的可重用性（reusability）與靈活度（flexibility）。
Reference: https://ithelp.ithome.com.tw/articles/10228461
JWT
微服務特點：
1. 一組小的服務
2. 獨立的 process
3. 輕量級通信 (SOA 重量級才務)
4. 基於業務能力 (登錄服務、商品服務)
5. 獨立部署
6. 無集中式管理
定義：
Loosely Coupled
Service Oriented Architecture
with bounded context (獨立的數據)
優點：
1. 強模塊化邊界
2. 可獨立部署
3. 技術多樣性 (Java, NodeJs)
缺點：
1. 分佈式復雜性
2. 最終一致性問題 (資料庫)
3. 運維複雜性 (監控容量規劃、可靠性、穩定性)
4. 測試復雜性 (分散各個團隊)
微服务架构介绍
https://www.cnblogs.com/javastack/p/14925269.html
微服務架構 導入經驗分享
https://www.slideshare.net/chickenwu/community-open-camp
微服务架构图
https://www.cnblogs.com/yaoyangding/p/17461767.html
微服務架構 - 從狀態圖來驅動 API 的設計
https://columns.chicken-house.net/2022/03/25/microservices15-api-design/
康威法測是微服務的基礎
將單塊應用拆分成多微服，每個團隊維護自己的服務，相互之間不干擾
從單體架構遷移到微服務
https://blog.csdn.net/xtayfjpk/article/details/123181575
https://mp.weixin.qq.com/s/VeeLTGVSUvgtil19rRhOPg
什麼樣的情況下適合使用 Microservices
什麼樣的組織架構更適合微服務
團隊負責：Architect -> Design -> Develop -> Review -> Test -> Deploy -> Run -> Support -> Architect
分層方式：
外部設備
Backend for Frontend (BFF) 聚合服務 (適合服務、邊界服務)
基礎服務 (核心領域服務、公共服務、中間層服務)
continue
https://ost.51cto.com/posts/14840
API Gateway
Sunday, June 18, 2023
交易型系統設計的一些原則
高并發原則
1. 無狀態- 設計應用屬於無狀態，可以水平擴展
2. 拆分
2.1 系統
2.2 功能
2.3 讀寫
2.4 AOP：CDN 就是一個 AOP 系統
2.5 模塊
3. 服務化
Saturday, June 17, 2023
Sunday, June 4, 2023
CDN Index
架設網站時當文章數量與圖片越來越龐大時，一定會發覺網站的加載速度越來越緩慢
為了要提升網站的加載速度很多架站的管理人員都會選用 CDN 服務來家快我們網站的讀取速度
針對靜態網路資源
提高網站可用性
解決問題：
1. 物理距離遠
2. 多次網路轉發
3. 延遲高不穩定
4. 所在運營商不同，需運營商之間轉發繞行
5. 網路頻寬處理能力有限，海量請求時，降低回應速度與可用性
步驟：
1. DNS query
2. DNS System
3. CDN DNS
4. CName
5. CDN Pop (ICDN 服務器)
透過 nslookup 查詢
有 2 台機器：
本地：home.edge.net
美國：us.edge.net
比較
本地：nslookup home.edge.net
canonical name = part-0024
美國：nslookup home.edge.net
canonical name = part-00424 (比較遠)
客户是怎么接入 CDN 的
假设客户的域名为：www.test.com
1. CNAME方式
腾讯云向客户提供的CDN是 $domain.cdn.dnsv1.com ，客户的域名 www.test.com 如果需要将请求切到腾讯云CDN上，只需要将 www.test.com 的CNAME 设置为 www.test.com.cdn.dnsv1.com 即可
CNAME方式的背后，又分为以下几种模式
1. CDN厂家提供基于DNS的调度，最终客户的域名经CDN的调度域名解析出CDN节点的IP。腾讯云CDN即采用这种模式。
2. CDN厂家提供基于302的调度，给的CNAME不是真正CDN节点，而是一个调度集群，真正的CDN IP地址是通过在调度集群上向请求响应302跳转实现的。腾讯云为一些手机厂家的下载业务提供过这种模式
3. 再有一种，是Anycast CDN。从DNS层面上看，CDN厂家提供给你的CNAME的解析结果只有全球固定的一两个IP地址，不像方式1中不同地区的解析结果IP不同。这种场景下的流量调度，不是靠DNS解析，而是Anycast BGP路由的调整，通过调整Anycast的路由来调度各地区的流量到哪个机房。
2. 调度域名深度定制方式
这种模式主要是一些代理商客户，即使用腾讯云CDN来接客户，又想在DNS层面隐藏他们使用的CDN厂商。一般做法是客户提供一个自己的域名比如： gslb.mycdn.com，腾讯云也提供一个中性的且不备案的平台调度域名 glsb.mycdn-platform.com。真正的客户域名 www.test.com CNAME到 gslb.mycdn.com ，后者CNAME到腾讯云的调度域名 gslb.mycdn-platform.com。这样整个解析环节都没有腾讯云的痕迹。
3. 域名托管方式
这种模式不太常见。以域名 www.test.com 为例，如果客户要将请求切往CDN，需要将 test.com 的NS记录改为 CDN厂商提供的NS 权威服务器。这时CDN厂商同时担当了DNS服务商和CDN服务商的角色。
DNS调度原理
浏览器首次请求目标URL，本地无p73.ping.dnsv1.com 解析记录，向DNS服务器（也称为 local DNS）202.96.134.133发起查询请求。
202.96.134.133（此IP背后的真实服务器）若本地无缓存，发起遞迴解析，最终解析到388957.p23.tc.cdntip.com，解析请求被发往cdntip.com的权威服务器 ns-open3.qq.com
ns-open3.qq.com并非一台实体服务器，而是网络的虚拟IP，先避开复杂的网络结构，其背后有一台或多台真实DNS权威服务器（或集群），为描述方便假设其IP为10.1.1.1
10.1.1.1 目前有的信息包括域名 388957.p23.tc.cdntip.com、local DNS ip 202.96.136.240。如果local DNS支持EDNS，那此时还能看到客户端IP 113.87.117.154
Reference: https://www.huidu.io/news/1270/
CDN网络架构主要由两大部分，分为中心和边缘两部分
1. 中心指CDN网管中心和DNS重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房
2. 边缘主要指异地节点，CDN分发的载体，主要由Cache和负载均衡器等组成。
当用户访问加入CDN服务的网站时，域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用户，使用户能够得到快速的服务
还与分布在世界各地的所有CDN节点保持通信，搜集各节点的通信状态，确保不将用户的请求分配到不可用的CDN节点上，实际上是通过DNS做全局负载均衡
每个CDN节点由两部分组成：负载均衡设备和高速缓存服务器
负载均衡设备负责每个节点中各个Cache的负载均衡，保证节点的工作效率
负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载DNS的通信，实现整个系统的负载均衡
高速缓存服务器（Cache）负责存储客户网站的大量信息，就像一个靠近用户的网站服务器一样响应本地用户的访问请求
Reference:
https://www.zhihu.com/question/21771529
Friday, June 2, 2023
DRM index
DRM的基本构成：EME、CDM、AES、CENC以及密钥和密钥服务器
AES
CDM
目的：
阻止特定国家的人群查看内容
允许用户在特定时间访问内容
防止用户将电影投屏到屏幕上
阻止免费用户访问付费内容
阻止在某些特定设备上的播放
在减少盗版以及确保内容创造者获取收益方面，DRM发挥了非常重要的作用
DRM是一个系统或解决方案，不同于加密
使用加密方法保护内容
用专业技术安全地存储和传输加密和解密密钥（比如7年级同学例子中的密码本），
并以一种不会使内容落入坏人之手的方法通过密钥解密内容
允许内容生产商设置商业规则，并限制观看人群（到期时间等）
Reference:
构建DRM系统的重要基石——EME、CDM、AES、CENC和密钥
Sunday, June 20, 2021
fiddler解密https数据
接着进行 https 解密的配置：tools--options--https
然后：这里勾选 解密https和忽略服务器证书的。
这里本来应该是会提示你安装fiddler的根证书的，然后表明这个有些风险。我这里由于之前安装过了，所以卸载了再安装没有提示了。反正对于弹出的框，你都大概看看，理解一下，然后，yes,赞同即可.这样的话就会顺利把根证书安装到本地。后面就可以查看https的数据了。
Actions -> Trust root certificate -> Yes -> 是 -> 是
Actions -> Export Root Certificate to Desktop
重新打开fiddler，就可以在电脑上进行https抓包了。
如果抓取的包都是错误的，需要注意把下面这几个反勾选掉。Autoresponder—enable rules
如果是非新安装fiddler，则先按照如下步骤清除现有的证书：
1、清除C:\Users\Administrator\AppData\Roaming\Microsoft\Crypto\RSA 目录下所有文件。
2、清除电脑上的根证书，WIN+R快捷键，输入：certmgr.msc， 然后回车，查找所有fiddler证书，然后删除。
Reference :
https://zhuanlan.zhihu.com/p/104407121
https://zhuanlan.zhihu.com/p/26177544
Friday, April 30, 2021
Fiddler Introduction
Fiddler 基礎知識
強大的抓包工具，它的原理是以web代理伺服器的形式進行工作的，使用的代理地址是：127.0.0.1，埠預設為8888，我們也可以通過設定進行修改。
代理就是在客戶端和伺服器之間設定一道關卡，客戶端先將請求資料傳送出去後，代理伺服器會將資料包進行攔截，代理伺服器再冒充客戶端傳送資料到伺服器；同理，伺服器將響應資料返回，代理伺服器也會將資料攔截，再返回給客戶端。
Fiddler可以抓取支援http代理的任意程式的資料包，如果要抓取https會話，要先安裝證照。
工作原理
關於 HTTP 協議
介紹請參考：http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html
請求方式常用的有：GET、PUT、POST、DELETE。
HTTP狀態碼主要分為 5 類：
1 開頭的代表請求已被接受，需要繼續處理
2 開頭的代表請求已成功被伺服器接收、理解、並接受
3 開頭的代表需要客戶端採取進一步的操作才能完成請求
4開頭的代表了客戶端看起來可能發生了錯誤，妨礙了伺服器的處理
5開頭的代表了伺服器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是伺服器意識到以當前的軟硬體資源無法完成對請求的處理。
常見的主要有：
200：伺服器成功處理了請求；
404：未找到資源；
500：內部伺服器錯誤；
503：伺服器目前無法為請求提供服務；
302：請求的URL已臨時轉移；
304：客戶端的快取資源是最新的，要客戶端使用快取。
Fiddler的使用
设置谷歌浏览器为代理服务器。
Subscribe to:
Posts (Atom)