我所理解的服務化

YFan 發(fā)布于2019-07-30 14:31 / 2259人閱讀

摘要：當不用服務時，非常容易寫事務或者其他邏輯保持數(shù)據(jù)一致性，服務化后難以做到這一點回滾可能都是調(diào)用服務，依然可能失敗不必要的服務間請求增多。

講故事環(huán)節(jié)

我先講個故事

很久很久以前（其實現(xiàn)在大部分網(wǎng)站都是這樣），我們做一個網(wǎng)站，所有的功能代碼都會在一個代碼庫中，部署的時候 db 幾臺機器、nginx 幾臺機器、業(yè)務 server 幾臺機器。其中業(yè)務 server 的所有邏輯都是在一個進程中的，例如網(wǎng)站的登錄、用戶的評論、新建問題、某個活動等等。

一起看起來很美好。

突然有一天，老板說我們搞個紅包活動吧，微信紅包，上線后由于中國人的薅羊毛心態(tài)，活動頁面 qps 瞬間暴增，導致網(wǎng)站的登錄邏輯 qps 也暴增，活動頁面壓垮的同時，所有其他業(yè)務全部504，擴容時也是整個 server 一臺一臺的加。擴容后發(fā)現(xiàn)，其實 qps 大的頁面就只有這個活動也，容器上其他頁面全部都是資源浪費。

所以造成上面現(xiàn)象的問題有這么幾個

降級邏輯，一個邊緣東西跪了不應該影響全站（除非是極為核心邏輯、例如登錄）

不能定點擴容

這時候就在想，如果登錄是一個服務，自己的業(yè)務也寫成一個服務，主站的其他業(yè)務不動，登錄、活動、主站業(yè)務分機器部署，活動 qps 來的時候我只要擴展登錄和活動的容器就好了。而且這樣在活動的這個服務中可以方便的接入登錄的降級。

什么是降級

簡單的理解，降級就是指需要被降級的東西跪了的時候，業(yè)務不會5xx。

土辦法的做法就是加 try except，這樣就會有這么一個問題，例如下面的代碼中，do_something 可能是 mysql 的一次寫，其他耗時操作的一次查，當 do_something 徹底跪了的時候，如果用 try except，每個 qps 來的時候，do_something 會依然執(zhí)行，例如 mysql 跪了起不來，do_something 每次都會去連接 mysql，然后500。

    try:
        do_something()
    except Exception as ex:
        logging.error(ex, exc_info=1)

那么我們明知道這個地方跪了，為什么還要一直打他呢？降級時可不可以在一定時間內(nèi)返回一個默認值，不去真實的做 do_something，或者在接下來的一定次數(shù)的 qps 返回一個默認值？

Hystrix的降級策略

所以什么是服務化

看看下面知乎的這個專欄好了

知乎服務化
知乎的一個回答
實施微服務，我們需要哪些基礎框架？這個撿著看

服務化的優(yōu)點和缺點

優(yōu)點

根據(jù)服務擴容簡單

降級容易做（就可以評論跪了整個網(wǎng)站其他功能還活著）

上線時只上自己對應的服務即可，不影響其他業(yè)務（數(shù)據(jù)相關還會影響）

缺點

業(yè)務拆分定級，否則會服務爆炸（是個功能就寫個服務，后期服務巨多無比）

數(shù)據(jù)一致性難以保持。當不用服務時，非常容易寫事務或者其他邏輯保持數(shù)據(jù)一致性，服務化后難以做到這一點（回滾可能都是調(diào)用服務，依然可能失敗）

不必要的服務間請求增多。不用服務時，很多東西查一次可以用上下文的形式傳遞，服務化后服務內(nèi)部可能需要自己重新查一遍。

批量接口難以實現(xiàn)

服務間解耦，一般采用消息系統(tǒng)（kafka），需要消息系統(tǒng)穩(wěn)定

非 rpc 層的單測是騙自己的，畢竟 rpc 調(diào)用的地方都會 mock

怎么服務化

業(yè)務拆分是逃不掉的，服務化后還需要慢慢替換原有實現(xiàn)。

我們重點說下技術手段

你可以選擇 rest 或者 rpc，協(xié)議的話 HTTP 開銷比較大，業(yè)界現(xiàn)在似乎比較主流的選擇是 thrift 協(xié)議，然后做一個 rpc。給出餓了么實現(xiàn)的一套 python 版本 thriftpy。

所以坑爹的點就在于，你拿到一套 thrift 的協(xié)議的時候，例如 thriftpy，他不像 django、ruby on rails之類的會有非常明確的代碼分層要求，如果內(nèi)部不在強行定義規(guī)范，每個開發(fā)寫出的服務都不一樣。

那么當你服務有多個容器后，怎么方便分組部署呢？首先你需要服務發(fā)現(xiàn) consul, 例如我們定義一個服務叫做用戶服務 member，他可能在物理機 A 3001端口，3002端口，物理機 B 3001端口起了3個 rpc server，consul 可以注冊一個 member，物理機端口的事兒同樣注冊在里面，業(yè)務方只要用 member 這個名字就好了，不必知道具體打的是哪一臺物理機的那個 server。

配套食用的可能還有 haproxy 做負載均衡的，我沒用過表示只知道這玩意兒。

你真的需要服務化么

這個是非常需要思考的問題。如果你的網(wǎng)站 qps 非常低，搞毛幺蛾子。

GPU云服務器云服務器常用的服務器理解我所對云服務器的理解我所知道

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/40752.html

我所理解的接口設計

摘要：前言自己做接口開發(fā)的時間也算不短了三年，想寫這篇文章其實差不多已經(jīng)有一年多的時間了。前言自己做接口開發(fā)的時間也算不短了(三年)，想寫這篇文章其實差不多已經(jīng)有一年多的時間了。我將從下面的方向來對我所理解的接口設計做個總結(jié)：接口參數(shù)定義 -> 接口版本化的問題 -> 接口的安全性 -> 接口的代碼設計 -> 接口的可讀性 -> 接口文檔 -> 我遇到的坑接口參數(shù)定義接口設計中往可...

taoszu 2019-06-28 18:33 評論0 收藏0
簡述我所理解的 PHP Trait

摘要：和組合的語義定義了一種減少復雜性的方式，避免傳統(tǒng)多繼承和類相關典型問題。隊列的目的是將耗時的任務延時處理，比如發(fā)送郵件，從而大幅度縮短請求和相應的時間。同樣的道理，根據(jù)引入不同的來完成對應的功能。 showImg(https://segmentfault.com/img/remote/1460000010868178); Trait 概念在常規(guī)的 PHP 開發(fā)中，我們都習慣于先編寫一...

gecko23 2019-06-28 13:33 評論0 收藏0
Why Kubernetes ，我所理解的docker與k8s

摘要：去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與。今天想先談談，我理解的容器是什么，以及為什么它們能火起來。一個容器鏡像的實質(zhì)就是程序進程加所有運行時環(huán)境及配置依賴的集合。這里再談談我理解的。而，就是目前的容器編排的平臺的事實標準了。去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與Kubernetes。邊惡補相關知識的同時，也想把學到的內(nèi)容和自己的理解整理出來。學習的途徑包括k8s官方文檔...

Taste 2019-06-28 17:03 評論0 收藏0
Why Kubernetes ，我所理解的docker與k8s

摘要：去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與。今天想先談談，我理解的容器是什么，以及為什么它們能火起來。一個容器鏡像的實質(zhì)就是程序進程加所有運行時環(huán)境及配置依賴的集合。這里再談談我理解的。而，就是目前的容器編排的平臺的事實標準了。去年換工作后，開始真正在生產(chǎn)環(huán)境中接觸容器與Kubernetes。邊惡補相關知識的同時，也想把學到的內(nèi)容和自己的理解整理出來。學習的途徑包括k8s官方文檔...

maochunguang 2019-07-01 17:05 評論0 收藏0
我所理解的原型&原型鏈

摘要：有以下幾點三圖片解析是原型鏈的鏈接通過查找到，是原型的關鍵字是實例對象是構(gòu)造函數(shù)通過找到所以構(gòu)造器的原型屬于對象，也就是說是出來的。同理找到，發(fā)現(xiàn)屬性，輸出五參考資料原型與原型鏈如果有理解不對的地方，歡迎大佬指正一、題目我們先看一道題目 var F = function() {}; Object.prototype.a = function() { ...

Allen 2019-08-23 15:32 評論0 收藏0