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

From: https://aws.amazon.com/tw/blogs/mobile/backends-for-frontends-pattern/

Reference:

Backend for Frontend (BFF)

Friday, June 23, 2023

微服務

五個系統設計常用的定律

* 墨菲定律 Murphy’s law

只要有可能出錯，就一定會出錯

* 高德納定律 Knuth’s law

在時機未到前優化是萬惡之源

* 諾斯定律 North’s law

每一個決定都是一次取捨

* 康威定律 Conway’s law

組織本身的溝通結構會反映在該組織所設計的系統上

* 帕金森瑣事定律 Parkinson’s law of triviality

組織成員會投入不成比例的心力在瑣事上

服務導向架構（Service-Oriented Architecture, SOA）

Microservices 是近幾年來軟體工程領域裡滿常聽到的熱門關鍵字之一。大概是在 SOA 出現後幾年開始崛起，跟 SOA 其實有 87% 像，所以最一開始 microservices 出現的時候，都還是被與 SOA 一同稱呼。兩者想要做的都是將一個單體式架構（Monolithic Architecture）依照功能拆成小塊，達到更好的可重用性（reusability）與靈活度（flexibility）。

Reference: https://ithelp.ithome.com.tw/articles/10228461

後端工程面試詳解-導覽

Catch Server

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/

RESTful API Design

CORS Introduction

康威法測是微服務的基礎

將單塊應用拆分成多微服，每個團隊維護自己的服務，相互之間不干擾

從單體架構遷移到微服務

https://blog.csdn.net/xtayfjpk/article/details/123181575

https://mp.weixin.qq.com/s/VeeLTGVSUvgtil19rRhOPg

什麼樣的情況下適合使用 Microservices

Reference: https://ithelp.ithome.com.tw/articles/10228461

什麼樣的組織架構更適合微服務

團隊負責：Architect -> Design -> Develop -> Review -> Test -> Deploy -> Run -> Support -> Architect

Iaas、Pass、Saas 傻傻分不清楚

分層方式：

外部設備

load balance

Backend for Frontend (BFF) 聚合服務 (適合服務、邊界服務)

基礎服務 (核心領域服務、公共服務、中間層服務)

服務發現

微服務三种服务发现机制

continue

https://ost.51cto.com/posts/14840

API Gateway

第01讲：什么是微服务架构?

第02讲：架构师如何权衡微服务的利弊？

第03讲：康威法则和微服务给架构师怎样的启示？

第04讲：企业应该在什么时候开始考虑引入微服务？

第05讲：什么样的组织架构更适合微服务？

第06讲：如何理解阿里巴巴提出的微服务中台战略？

第07讲：如何给出一个清晰简洁的服务分层方式？

第08讲：微服务总体技术架构体系是怎样设计的？

第09讲：微服务最经典的三种服务发现机制

Sunday, June 18, 2023

交易型系統設計的一些原則

高并發原則

1. 無狀態- 設計應用屬於無狀態，可以水平擴展

2. 拆分

2.1 系統

2.2 功能

2.3 讀寫

2.4 AOP：CDN 就是一個 AOP 系統

2.5 模塊

3. 服務化

微服務：了解 Dubbo 核心概念和架构入門到實戰

網站架構核心技術

交易型系統設計的一些原則

Saturday, June 17, 2023

Web index

WebAssembly

[論文] 好像沒有那麼快：WebAssembly vs. Native Code 程式碼效能分析

WebAssembly 實戰 – 讓 Go 與 JS 在瀏覽器上共舞

New Relic

深度剖析什麼是 SLI、SLO 和 SLA

Fiddler

video player

dplay

網站架構核心技術

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技术详解及实现原理

阿里雲CDN加速原理詳解

CDN网络架构主要由两大部分，分为中心和边缘两部分

1. 中心指CDN网管中心和DNS重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房