大規模業務服務器開發總結

jopen 9年前發布 | 9K 次閱讀 服務器


大比小好

開發階段,服務不穩定,一個大服務不如一堆小服務; 運維階段,服務都穩定了,一堆小服務又不如一個大服務。

大規模的時候了,如果能夠一個進程搞定的,盡量不要拆兩個進程。

少比多好

如果都是大服務,自然而然地,服務數量就少。

服務數量少,運維成本就相應低。

快比慢好

一個進程,跑得越快,qps越高,所能使用的資源越多,越能“物盡其用”。

直連比隊列好

常見的進程間內網通訊,一般會使用直接的rpc或者是mq來中轉。然而,在一般的情況下,引入mq會給服務化帶來復雜度,使容量問題更加隱藏。

特例監控比共性監控好

強烈要報警的監控一定要是開發手工加到代碼里去的,只要報警,一定是代表了可用性降低,不應該有二義性。共性監控如cpu、硬盤、內存等,只能算是知會性的報警,一般不會影響業務的可用性。

進程外負載均衡比進程內好

負 載均衡邏輯放到一個獨立進程的好處在于,這部分邏輯不常改動,同時不應該受經常上線的影響,最好是724365全天候足夠穩健的服務。進程內的問題在于, 當業務代碼與負載均衡代碼改動頻率完全不是一個量級時,雙方都將在上線,同時任何一方的問題都將相互影響; 更大的一個問題是,推動所有服務一起更新負載均衡策略難度遠大于更新一個專門的進程。

有層級的服務比普通SOA好

SOA要求我們把各業務邏輯服務化,沒有層級的服務化就是噩夢。主要服務之間一定要有金字塔一樣的規則,否則會對各種跨機房、遷移等帶來麻煩。

kv存儲比RDS好

只用kv,存儲層維持狀態,擴展、遷移都大大降低難度。使用rds,qps變化時延遲并不是線性變化,kv就能保證這點。維護狀態的一層大多在db,以kv這樣容易擴展的方式,更加利于未來的遷移和擴張。

無狀態比有狀態好

服務帶上狀態,以后遷移、擴容各種毛病,只要有一個理由可以不要狀態,就一定要無狀態。

閉源比開源好

開源項目都是解決共性需求,規模越大,越是有特性,越不可能開源,閉源可以省很多事。


原創文章如轉載,請注明:轉載自五四陳科學院[http://www.54chen.com]

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!