書接上回，我們一起體驗了reactor模式，也了解到了其解決什么場景下的問題。
我們將一同感受一下協程的魅力，基于本系列文章最開始的例子 a + ((b -c）+ d) -e -f + g, 本文將使用協程的方式來實現，并與之前的實現方式進行對比。
Kotlin協程解決方案
本節依然基于vertx，同時利用kotlin的協程，來實現 a + ((b -c）+ d) -e -f + g 。
需要讀者對vertx和kotlin有一定了解，準備工作可以閱讀 [vertx-lang-kotlin-coroutines] (https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/) 和 coroutines-guide。
下面直接貼代碼，可以與之前的promise和reactor模式的代碼進行對比，實現的功能是一樣的。
suspend fun calc(context: RoutingContext){
var a = context.request().getParam("a").toInt()
var b = context.request().getParam("b").toInt()
var c = context.request().getParam("c").toInt()
var d = context.request().getParam("d").toInt()
var e = context.request().getParam("e").toInt()
var f = context.request().getParam("f").toInt()
var g = context.request().getParam("g").toInt()
var result = a asyncAdd ((b asyncSub c) asyncAdd d) asyncSub e asyncSub f asyncAdd g
context.request().response().end(result.toString())
}
suspend infix fun Int.asyncAdd(input : Int) : Int {
return calc(this, input, CalcOperator.add)
}
suspend infix fun Int.asyncSub(input : Int) : Int {
return calc(this, input, CalcOperator.sub)
}
suspend fun calc(a: Int, b: Int, operator: CalcOperator) : Int {
return webClient.get(7777, "pi", "/${operator.name}?a=$a&b=$b")
.expect(ResponsePredicate.SC_OK).sendAwait().bodyAsString().toInt()
}
可以看到代碼精簡了許多，其中最核心的計算邏輯就在這一部分：
var result = a asyncAdd ((b asyncSub c) asyncAdd d) asyncSub e asyncSub f asyncAdd g
這是一種同步的代碼書寫方式，如果我們需要添加額外的業務邏輯或異常處理邏輯，就很簡單：
var r1 = b asyncSub c
if(r1 < 0){
r1 = -r1
}
var r2 = 0
try {
r2 = a asyncAdd r1
} catch (e : Exception){
//異常處理邏輯
}
...
這就是妥妥的大多數人最熟悉的編程方式 --- 命令式編程，if ... else ... try ... catch ...，相信剛畢業的學生也可以駕輕就熟。就解決異步執行編排問題上，相比于promise模式、reactor模式，代碼在書寫難度和可讀性、可維護性上都有明顯的優勢。
(完整代碼 包路徑有點亂，請無視)
如果我要提升并發度，也可以利用async和await關鍵字來重構，我們把計算式進行數學轉換為 a + b + d + g - (c + e + f), 然后把計算進行并發改造
var r1 = async { a asyncAdd b }
var r2 = async { d asyncAdd g }
var r3 = async { c asyncAdd e asyncAdd f }
var result = r1.await() asyncAdd r2.await() asyncSub r3.await()
這樣 a + b, d + g, c + e + f三個動作，四次網絡請求就可以并發執行，可以降低總體耗時。
golang 的協程解決方案
//a + (（b -c）+ d) -e -f + g
func sayHelloName(w http.ResponseWriter, r *http.Request){
r.ParseForm()
a, _ := strconv.Atoi(r.FormValue("a"))
b, _ := strconv.Atoi(r.FormValue("b"))
c, _ := strconv.Atoi(r.FormValue("c"))
d, _ := strconv.Atoi(r.FormValue("d"))
e, _ := strconv.Atoi(r.FormValue("e"))
f, _ := strconv.Atoi(r.FormValue("f"))
g, _ := strconv.Atoi(r.FormValue("g"))
bSubC, err := asyncSub(b, c)
errorHandler(err)
aAddD, err := asyncAdd(a, d)
errorHandler(err)
eAddF, err := asyncAdd(e, f)
errorHandler(err)
bSubCAddAAddD, err := asyncAdd(bSubC, aAddD)
errorHandler(err)
bSubCAddAAddDSubESubF, err := asyncSub(bSubCAddAAddD, eAddF)
errorHandler(err)
result, err := asyncAdd(bSubCAddAAddDSubESubF, g)
errorHandler(err)
fmt.Fprintf(w, strconv.Itoa(result))
}
func errorHandler(err error){
if err == nil {
return
}
panic(err)
}
func Start(){
http.HandleFunc("/", sayHelloName)
err := http.ListenAndServe(":9090", nil)
if err != nil{
log.Fatal("ListenAndServe: ", err)
}
}
func asyncAdd(a, b int) (int, error) {
return asyncCalc(a, b, "add")
}
func asyncSub(a, b int) (int, error) {
return asyncCalc(a, b, "sub")
}
func asyncCalc(a, b int, operator string) (int, error) {
url := fmt.Sprintf("http://pi:7777/%s?a=%d&b=%d", operator, a, b)
r, err := doHttpGet(url)
if err != nil {
return 0, err
}
result, _ := strconv.Atoi(*r)
return result, nil
}
func doHttpGet(url string) (responseBody *string, err error){
resp, err := http.Get(url)
if err != nil {
return nil, err
}
defer resp.Body.Close()
content, err := ioutil.ReadAll(resp.Body)
if err != nil {
return nil, err
}
result := string(content)
return &result, nil
}
可以看到基于golang的協程，一樣是同步的方式；不過“得益”于golang的獨樹一幟的異常處理機制，代碼寫起來沒有鏈式的那么好看。
總結
協程最關鍵的優點是吧代碼的執行和操作系統線程進行了解耦，代碼阻塞但線程不阻塞?？梢宰岄_發人員以同步的方式寫異步的代碼。真是異步編程的大殺器。
系列文章快速導航：
異步編程一：異步編程的魅力
異步編程二：promise模式
異步編程三：reactor模式
異步編程四：協程
