请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 249|回复: 0

蘑菇街的DeVops实践

[复制链接]
来自- 日本

参加活动:0

组织活动:0

发表于 2018-10-26 16:44:32 | 显示全部楼层 |阅读模式 来自- 日本
本帖最后由 adminlily 于 2018-10-26 16:52 编辑
" p3 T* x7 |4 B* V: Q/ t3 V
3 h5 u) e$ ~+ V8 r
1.png
蘑菇街技术架构演进过程
  J6 K9 j/ P+ K! ^) Z% D
) s& I3 \3 I  T" z/ a! N- H. P4 j
早期2011年,产品形态是导购,业务量不大的情况下,技术架构选择了相对简单的LNMP架构。通过PHP快速开发,让业务快速运转起来。所以,当时主要以开发人员为主,没有专职的运维的团队。+ @  \9 m4 X7 l6 f. [6 Z5 r

. s0 A/ A6 U, N$ w. e
$ h+ l  M. i/ L& Q( a& s
1.png

# p0 S) [# I5 u- L5 I
2013年转型做电商,整个技术架构也没有发生太大地变化,还是以LNMP架构为主。不过在业务从小到大的快速发展过程中,最容易出现瓶颈和问题的是DB的连接、缓存的连接等这种连接数的资源,蘑菇街在这个阶段也遇到的同样的问题,所以架构上的调整,主要是DB中间层和缓存中间层的增加为主,但整体上还是LNMP。
9 d  `% \2 s) C' N

, F! {3 v( E1 D: J$ _* f2 F8 Z. T
4 X8 s+ U" T4 S- b6 o- ]

" B" X: J# [% k6 Y! q
1.png
2 d8 M( a$ S0 F% p- ^
随着业务发展,业务也开始变得丰富和复杂起来,带来的不仅仅是用户量、业务量这种体量上的增长,业务自身丰富度和复杂度也在发生着非常大地变化。对技术上带来的挑战和问题,如下图所示:

" D0 R. A: _( b- j1 [
/ l' @; J" j$ S+ p' ]: L5 i3 ]

/ L9 x0 B! V9 G( W0 s* P+ U
1.png
9 {* W6 j1 y0 h
可以看到PHP的工程变得异常的臃肿,因为有太多的业务需求需要开发,有太多的开发人员在同时开发,结果短期内PHP的代码工程就造成了局面。

, p7 X) o+ t9 i9 I* U6 U

5 `9 c* [" w( R7 @- {( x
首先谈到PHP的优势,PHP上手非常快,入门门槛相对低一些,一个新手从学习到开发生产系统的代码的周期相对较短,同时,PHP部署发布的效率也相对简单,PHP文件发到线上即可运行,不用复杂的编译、打包和启停动作,在业务前期发展阶段,PHP效率上的优势就表现的很明显。但是,上图所示,随着业务的发展,业务类型越来越多,开发的人员也越来越多,大家都往一个工程里面去写代码,势必导致PHP的工程越来越大,越来越臃肿,给后续的代码维护带来了很高的复杂性。
8 z, v% K2 z+ {9 Z* ?- m

* L( ^3 W; T$ a
举个例子,对于一个开发的人员来说,如果他要做的功能和需求涉及到其他人的开发的PHP文件,本来这个功能和需求在原有的程序上改就行了,但是因为工程太大了,他可能是没有办法评估清楚说改了这一个文件,对其他的文件、接口和方法会造成什么样的影响,即使能够评估清楚,也很难保证在测试的时候把这些所有的点都能够测试到,根本没这么大的精力。所以就导致很多开发人员会不断的Control C+V,就是宁可是把需要改的文件Copy一份出来,然后在Copy出来的文件上面做开发,原来的功能不动,这样就保证了新需求可以不影响老公能,但是这个状况就会导致进一步加大了PHP工程的臃肿,实际上是一个恶性循环。再就是,如果碰到非改不可的PHP底层的文件和代码,如果评估不到位,就是导致出现各种各样的线上故障。所以,到了这个阶段,PHP代码就很难维护了,反而影响到了需求和版本的迭代速度。
: L: I" ?8 H7 g( H& }9 Z8 ^. u3 x/ B
4 w0 H% [8 I9 |3 Q% ?; C2 z- y
这种情况下应该怎样办呢?需要选择业界比较通用的方案-Java服务化,把大的工程拆分成一个个小的应用,通过服务化框架提供RPC的调用。这个阶段,从PHP转向JAVA,从单一工程转向了分布式服务架构。

! Q8 k! I3 j! W# B* u
- W/ @& o4 {2 v5 _( W2 z

8 G% g. ^! s% i* z) R, S; p9 G
1.png

9 S  j1 s8 S# a/ H- d
经过拆分后,整个架构就变成了现在的这个样子。这样看下来整个架构分了很多层,也有很多的细节,乍看上去是比刚才的架构图要复杂一些。但是这样的架构根据条理性,也会让架构里面很多的技术细节都曝露出来,更加便于管理。相对那刚才非常庞大和臃肿的PHP工程,内部的逻辑、方法和接口的依赖等等,是很难梳理清楚的。
  r8 ~7 e! {4 F/ P
9 D2 e* i9 M' w' J

; v9 W3 o$ r2 Y, x) v# `) U9 T

$ m5 m4 |' M2 T2 A0 Q. O# G
1.png
2 c0 H; P1 F: c  N; d( N
下面主要讲做了JAVA服务化的技术转型后,对运维带来的挑战是什么:

: r- f( I9 e* G

, h6 r6 Q) k6 q& c
1、服务化应用的管理问题

9 h4 |7 v* u0 s+ A8 r# M2 T5 V* A
1.png

7 L9 A) i$ l  \: V: p2 U! y* t
2 N4 ~+ u" d/ D: y
2、服务化之后的服务治理问题
( m6 [& U5 `! ?; V" n$ t

9 V8 q, a  N# @. K; Q
1.png

; y! n9 S# i, w, F5 h0 W7 B: o% O* i" i6 N, Y

: M+ k' c" {2 a6 Y6 z. x) G
  运维解决方案和思路
9 ]' x0 S" A: e9 h# z. [" |# i
5 }7 P3 l2 n/ l6 u" ^5 s: x
运维基本上要围绕着以下5个目标开展,效率、稳定、成本、体验和安全,重点从效率和稳定这两个方面去讲。

7 S) B* t" y8 \
0 A5 `% q* U( p! X. r/ C
: h/ e* N7 t: n$ _
1.png

3 M6 T% }' U6 @) _
从0开始应该怎样做,一定要从标准化开始,并围绕标准化展开。关于标准化,不管是做运维平台也好,还是运维体系也好,或者运维系统也好,第一件事要做的一定是做标准化。
1 p. P( h0 c' D. D8 {2 S9 o. Z
! h% _# F5 c7 D/ e2 ]/ G3 J. C
标准化主要做三方面的工作,第一是基础软件及基础设施的标准,主要是操作系统的版本必须统一,内核参数统一,基础设施上,用KVM虚拟化技术将我们的资源做成2C2G、8C16G这样的资源模板,确保资源配置的统一。第二是应用及配置标准化,这个后面细讲。第三是技术架构标准化,技术架构这块分接入层、中间件技术、缓存、DB等,关于技术架构标准化,它的重要性和它的意义在案例中体现出来。
2 O. X3 ?  l6 G. [+ h$ Q7 p, ?5 ?
' K5 ]2 Z8 h: h/ U) M/ P

# f  X' P# B# r; s( y
1.png
# ^! N+ f9 x8 ~5 w; [; E3 F" O2 b& H
/ u7 z" Q/ ?5 J5 \
! p: S7 B( L/ i( Q* A
举个例子:
0 G3 G: t" X5 n; B. u/ b; t0 Z8 T
1.png
  P7 Z, Y, T- H8 W& c
在做整个运维平台之前,首先将整个系统梳理一下,然后看一下整个系统里面到底有哪些基础环节和软件,应用到底有哪些应用类型。把这些东西一条一条地记下来,然后归纳总结,慢慢的就形成了左边的集团标准化,包括应用管理的标准化。基础服务的标准化,安全的标准化,稳定性的标准化,全部都制定清楚形成文档。
8 f5 Q( ?7 ?+ e( y* Q

; C; F+ c- O0 ?% d, a! }; i
把标准化的动作做完以后,如果只是纸面上的,那它的威力是没有显现出来的,如果仅仅是以写脚本的方式去管理它,实际上还是有点笨拙,所以再往后就做了这样一个应用配置系统,目的就是把做的标准化沉淀在技术平台上面,可管理,可提供服务。以上的样例就是我针对Java的标准,它的目录,起停的脚本等,通过一个应用模板固化下来,比如实际应用过程中,典型的Java应用,是Nginx+Tomcat的运行方式,那在应用配置管理中,就会有应用模板、基础软件和应用配置文件管理几个模块来管理。+ q( d' z7 e/ \) I

6 r: {4 p1 j' A: K
: Z9 N1 Y9 }. G  t5 B# F
1.png

, X; W* u7 r) t" [9 L' @: ^; @
以上这部分,是针对标准化,最后通过应用名这个核心将上面所说的这些零散的标准项给串起来,也就是常说的以应用为核心的运维体系。
0 W( K. p  L# v1 i& K1 U

  s" J6 T9 C% ^
* T' J  ~- Y. x, K4 d, [% s8 d" f" {
  案例分享, y& G' v6 J! C
, q3 H1 K# I( T7 l7 X. L, L
" z- d/ [, e: c* N* G2 \
一、持续交付, b# ]4 }2 r/ R/ \0 f' t7 Z
) [0 K* f" a# g7 [  s
) k' {, V% q! {9 K- o0 V' l& H- O( r
做完了标准化及标准化管理以后,遇到的比较棘手的问题就是这么多的应用应该怎样高效发布,这就涉及到持续集成和发布的问题。原来的PHP工程,只要在一个PHP的文件里面把代码写好,把文件推送到服务器上,然后最新的PHP文件就可以直接运行起来了,不用做中间环节的管控,但是对于Java应用来说整个环节就没有这么简单了,Java文件涉及到编译、二方包、三方包依赖,然后编译打包后,将软件包发布到制定的机器上,然后还要重启Java进程,最新的文件才能得以执行,期间还会涉及服务的注册和下线问题等等。

9 v6 J$ J7 t- }$ j0 W( }' Y1 M
8 @2 Z% K1 R3 {) v
从整个过程来说,JAVA整个发布过程是要比PHP复杂很多的。所以为什么要去做持续集成,对于这个持续我的理解是怎样能够把中间环节它的效率尽量提升,减少人为的干预,通过发布的自动化,提升开发和运维的效率。
# Y6 @( [! a( L6 E

# b7 Y$ R3 B2 V9 \2 d
1.png
) s5 V. ~. M, Z# \
接下来做的发布系统,提炼一下,发布做的事情就是,将提交后的应用代码,进行编译打包,然后发布到应用对应IP主机的指定目录下,并且做到应用服务的优雅上下线(或者叫做优雅启停)。
( [! z# x# I7 T5 k5 l5 Y' q2 m) L
8 G' @# B( x" [4 j0 J# M0 y
可以抽象出发布的最重要的三步,如下:
+ n* U7 F2 ?* B6 s; |3 q9 `

; l# M0 f3 p" h' |* r+ ]0 |

" c2 c8 X! E1 G7 c, w* i+ l
1.png
下面就分阶段详细描述三个主要环节:

- q& o  J8 a* e+ {5 J

7 j$ m# T6 W: _+ U- X" K. Y  P
1、代码提交环节(分支合并管理)

+ p" [4 s; P: E: S: Q$ B
2 g# K$ l. k9 X) N& K7 c  _3 ^2 l
代码管理工具是Gitlab,代码提交过程中最重要的就是对于分支合并的管理(这里又涉及到标准规范的制定),策略示意大致如下:
! o) L0 f& G$ a
) c! O9 l- l( U: o
1.png
描述如下:
2 v1 }  }1 I4 m6 J

5 x! ^1 b& m" }/ g1 d6 T
1、master分支,跟线上应用代码保持同步,也就是说随时可以发布到线上进行部署运行。

& M! \# o3 W  @+ @% I. H

2 {  x' H4 H" `! I
2、开发分支,通常以feature/defect来表示,比如开发一个新的需求,就会以当前master为基线,拉一个feature分支出来进行开发,同一个应用可以同时存在多个feature分支并行开发。
% K, V/ C& v& i4 d9 D! d/ r
6 E' x, e7 e, K' V2 h  b/ z3 x
3、发布分支,以release表示,在发布时会将所有提交集成的代码commit合并,形成release_环境_时间戳为分支名称,比如release_dev_01_29_20_52_10 就代表该分支是在1月29号20:52:10在dev环境发布时创建的临时发布分支。
0 W$ F9 |, N: Z6 |

" W% Z1 ?* b# R0 K; ?! f
4、从预发进入线上时,会以当前预发环境的发布分支release_pre_xxxx为基线创建一个release_online分支,作为线上的发布分支,线上发布结束后会把release_online分支合并到master中,这也就保证了发布到线上的代码最终一定会跟master的代码保持一致。

" T+ @3 e2 t3 A5 X" W5 U& G
9 ^$ A( ~$ ?0 {; d0 |$ j) ]
2、编译构建环节
4 v: G  ~7 N/ ^

2 j! v6 L# Q% g/ [( ?4 |7 @
以上介绍了代码提交环节,下一个环节就是要构建了,以Java为例,构建用到了两个工具,Docker和Maven。Docker主要用来提供一个干净独立的编译环境,Maven作为依赖管理和打包工具。整个构建过程如下:
6 v' P+ }9 H6 n$ x- h
1.png
' t: U8 U0 d3 J; F4 B) `& X2 N* T* j

! L+ u+ b% [' l0 X

+ K1 |5 ?" w- F9 l& I/ L9 j
以Java为例,简单描述如下:
; a' ]& k+ N! l. i: U

7 ^& B1 _6 o( g# y* J3 N
1、首先准备好JDK的编译镜像,这个镜像环境与线上环境保持一致,当有新的构建任务进来时,就创建一个对应的Docker实例进行代码编译;

/ [% P, k7 ]7 \7 M, y; B! N: C
1 M2 m1 a; M5 F! i' A" [1 y
2、构建任务会根据应用配置管理中的Git地址,将代码clone下来放到指定的编译目录,Docker实例启动后,将编译目录挂在到Docker实例中;
( |+ v, k; {- |+ e8 G

  l& l6 b: Y. ~' H, j' R
3、对于Java应用,在这个Docker实例环境中,就可以执行mvn package命令打包了,最终会生成一个可发布xxx.war的软件包;
7 k/ @1 v+ A2 {4 t3 S1 t

! Y" x4 l  P# z9 J
4、同样的,对于C++,Go、NodeJs,也会准备好类似的编译镜像,不同的是打包时,对于C++是cmake&make,Go就是go install等等,最终也会生成一个可发布的软件包;
$ K) T0 K  K- B& z, W" m
4 @$ K4 Y. L9 {1 \8 P, g0 \
5、构建完成后,Docker实例销毁;

3 e# k+ Y7 J% j9 J

5 G( W" @' d' K0 s- N3 G6 N$ F
这里面Docker发挥了一个很大的作用,就是提供了干净的,互不干扰的编译环境,且对于并发打包的情况,Docker快速创建多个并行的实例出来提供编译环境,使用完销毁,这个效率上的优势也是非常大的。
7 [* ^! u8 D  s/ v* b
# g  W4 K+ X1 t) a8 r
6、关于配置管理,当时设计时考虑比较简单,做法是同时做三个配置文件出来,dev_pom.xml,pre_pom.xml,online_pom.xml,分别对应开发、预发和线上三个不同的环境,根据发布的环境不同,将不同的配置文件替换上去。这样做其实可扩展性不够,对于多机房、多分组的情况会有更多的配置文件创建出来,且对于有敏感信息的配置项保密也不够(不过这些配置都已经加密挪到中间件的配置中心了),更好的办法可以考虑采用阿里早已开源的auto-config方案。
4 r  R) v( m% N
/ \5 U0 B, x/ X# e
3、部署环节

) ]* C9 w+ N7 O! J" y* ?5 m3 v, c

+ i! a4 |6 w; @: e+ U" E
以上,代码提交和编译构建完成后,就该进入发布到线上的部署环节了,也就是将代码发布到应用对应IP主机的指定目录下,并且能够优雅的上下线应用服务,貌似很简单,但是,看下图:
: v  v  I! K+ T. m* \
0 q7 o! i; L& f* n5 q

! ]4 Z9 X3 R# y. i( _
1.png
) c8 j# z( U9 ]7 P& y" p
这个过程的环节还是比较多的,这些环节内部又会有很多的细节,所以整个部署环节是很复杂的,下面将整体思路介绍一下:
8 @: \' W/ Y1 O3 p) ~

2 x+ X5 V$ f7 P, K4 R. h! m
0、从CMDB中,拿到应用-主机IP对应关系,然后再从1开始做,后面的过程可以是针对单台机器做,也可以是分批或分组多台机器同时做。(从第0步开始,原因就是上一篇文章里面说的CMDB和应用配置管理的基础要先打好,这个基础没有,下面的环节就无法顺畅地执行);
" _# y  @# i& C4 v% _3 P" @

( D5 j% U! c( z! h8 ]! ?; k
1、检查每台机器上的服务是否正常运行的,如果是正常服务的,说明可以发布,但是服务本身异常,就要记录或跳过了;

  v. \3 T$ y& k  e

* M( |6 w0 `, O  G( f7 S4 b
2、下载war包到指定目录(应用的目录信息,应用配置管理又发挥作用了);

! }  Q* H$ o* b8 f

4 K8 @! H: t( d* X% u2 @+ ?  x
3、将监控关闭,以免服务下线和停止产生误告警;
- ?1 D! `1 M! }0 M6 J- @* U' Z, a* G5 w
; O7 L7 j; W5 {/ g6 f* U
4、优雅下线,包含RPC服务从LB下线或Web服务从Nginx下线(如果不提供http服务就不涉及),下线动作均通过API接口调用方式实现;

0 L. b, j% ]* ^

) `9 t, Q8 {) c: J9 r- n
5、下线后自动检测无新的流量进入,停止应用,发布代码,然后启动应用(这时应用配置管理里面,启停命令等等就又发挥作用了);
3 w" R- G! R2 ]. Y9 w8 _* Y, j
. p. D  }/ v( f8 J6 ]
6、优雅上线,进行健康监测,检查进程和应用状态是否正常,如果全部监测通过,开始上线服务,开启监控;
: J( K6 t$ W5 R# \/ n
' Y0 e' q$ R& x5 L! R! l# x
7、分批发布,这里简单提一下,假设我们一个应用有100台主机,这个时候做发布不可能全部一把停掉,这样服务会中断,但是也不能一台台的做,这样效率又太低,所以我们可以折中分批发,比如可以分5批,每批20台,也可以分10批,每批10台,这样既可以保证在线升级,也可以保证效率能够跟的上。当然复杂一点,还有分组分批,或者按步长分批,第一批5台,第二批10台,后面每批20台等等。示例如下:
( }& a7 H1 A5 M4 g& x1 ~7 n: T) |

/ T9 K( d1 [! M) o8 I/ \3 z
整个过程下来我们可以看到:
) `0 W, W1 P( n9 e

3 l7 c* x8 m5 E& x6 b- V( _
1、基于场景入手,将业务流程梳理细致,做到细分环节,每步自动化,流程串联
8 C0 i4 p/ k) V
  v( X7 S+ b1 ^/ U9 q' N
2、上篇文章提到的CMDB和应用配置管理的内容,在这一部分无时无处不在发挥着基础的作用

7 {3 W. w- e: A+ e# b2 |

9 Z5 E: Q* \0 ?; f- _% t
效果:NoOps or DevOps
3 I' Z: v$ i6 V

1 e0 d  f% x2 ]' r% X) B& D4 v
发布系统上线后,整个过程已经可以做到开发全程自助发布,之前运维还在参与审批,后来审批环节也省略,在发布这个过程中,全流程NoOps。效果如下图所示:
# }/ S  ^# c* N0 }$ Y
0 q  Y. A6 ^4 h" M' {/ N2 N

3 J# [- }( _" @; |3 l1 H& W
1.png
/ g5 t8 w# j: ^4 G) y

) s! T4 P$ t7 J# m! `

1 t" g0 k" X- i! y% l
4 w1 _' U$ B; N  c4 U: S, @/ X9 s
  p. W* V+ x% [+ ~6 [8 _0 z* Q
4 U" t4 V9 _1 x: b1 B( ]$ Y7 L+ t
二、稳定性建设

0 ^) ?5 u6 p8 S4 f
0 T) m9 M2 |2 f) i& e

! Y7 B0 q# L  E
从0到1做完以后,效率问题基本得到解决,但是系统的稳定性这个矛盾马上就凸显出来了。经常遇到的问题是系统慢了,系统宕了,或者是突发流量非常大,会碰到这样那样各种诡异的问题。所以这里分享稳定性建设这方面的内容,主要分为:

3 t6 p/ H- {3 C; q0 i/ ?, W; X
4 r6 S* F. T1 B5 {& B
1.png
! r4 [6 W# v  r. s* W( N8 h

  e/ |- G0 p( v6 y' o4 n

3 T- N# F+ j7 ~1 \4 d* X8 B
主要介绍全链路跟踪系统。首先,为什么要做这个事情?

, B) ^: S9 A$ R7 @+ o
1.png

6 l! \: R7 T7 g# S3 F0 G! ]: E
. u- W! W, U9 X( P/ Y! Z! T: D, U
' @0 Q/ z) P6 h  F' H
这整个的全链路的架构图,在前端的应用上面会做埋点日志,然后通过Kafka放到实时日志集群里面,这样可以快速看到实时的数据,然后对于历史的数据,放到Hadoop里存储。/ w+ m1 T- _) [6 Z

2 C* P+ C+ J* h7 t
1.png

; m$ \0 s6 N: e6 B* Q

9 v0 D4 V- y+ `3 r5 X6 Q' z) g# R2 M
; w# J; S6 {" k) c: w/ H6 K/ B! x
这里要介绍关键的技术点,其中最关键的就是TraceID,当一个请求到达接入层,会在接入层生成全局唯一的TraceID,由我们自研的Nginx的module实现。然后后续的后端接口或方法调用都会把这个ID带上,这样每一次调完会成都会输出一条日志,把本次请求花费多长时间,调用哪些接口记录下来,这样通过刚才实时的Storm集群就可以计算出整个的实时请求是怎样的。
0 R) p/ _, I/ X9 |9 w
. E0 V! D/ U6 J2 U# W1 x# C3 Q
这里呼应为什么要做技术架构的标准化,这个TraceID是通过Nginx的module生成的,在ID透传的过程中,每一个请求都会从框架层面把这个ID自动带上,业务层面是不用考虑对这个ID单独做处理的,对于http请求,就是自动带上这个参数,对于RPC调用,通过分布式服务框架来处理的。所以接入层架构、分布式架构的这样一个统一的技术栈标准化之后,落地这样的稳定性方案其实就非常顺利了。假设这个标准不统一,Nginx大家有用原生版本的,有用Openresty的,有用Tengine的,或者直接用了Apache,这个module是没法统一定制的,对于分布式的框架,如果有用dubbo,HSF、Thrift的等等,也会无法统一。
  w' M. D, S" W. [" b

9 ~8 ]: u& I$ H. U) Y
8 n: p  g! e. A8 h$ b( w$ x
1.png

3 I# M6 W+ K# x9 [3 A; X, }* `6 \

' w- Q" o, h. O( d: x/ S
样例:
+ S9 `: j7 x8 [8 p5 ~

) F+ z9 S( I* m9 _6 K% {$ e
1、发现页面慢了到底怎样去做。经常遇到的一个情况就是页面慢了或者是某个页面慢了,根据问题反馈的时间点,可以进行筛选。这个时间段内,请求超过1秒的有哪些,筛选出来后,以TraceId为入口,那接下来整个请求的过程就展示出来了。从这个界面上我们可以很明显的看到,整个请求花了1.5秒,但是下面红色的地方有一个评价的服务,单这个服务接口的调用自己花了1.3秒,肯定是这个服务出了问题,这时候可以大大缩短问题范围的缩小,根据这个IP,直接到这台主机上检查发生了什么问题,后面就可以进入到详细的问题定位阶段。

' _6 g0 q  c) R) j
2 ]# F) D8 ]6 f. n
1.png

9 m, ]" O& Z+ }
2、调用合理性的问题。一次请求下来耗时非常长,但是看每一次的接口调用RT又是非常短,问题出在什么地方。比如下面这个这个请求花了1.8秒,但是每次请求都是了正常的,不像刚才一样,有一个请求自己占了1.3秒。这时候通过全链路可以看到,这个请求在频繁的重复的调用一个Cache接口,很显然在调用合理性上出现了问题。这时就可以把问题反馈给开发,检查下代码的逻辑,为什么这么调用,是不是应该优化下调用方式。

7 o7 ^1 a8 C) D" j. M2 N

+ S% i$ I2 N7 f3 ~7 I/ B4 X! M
1.png

7 u) S( n: X  ?7 q+ s' d
3、链路分析。一个应用提供出去以后,一个应用又包括了很多服务化的接口,而应用仅仅是成百上千应用当中的一个,这当中有哪些应用依赖了我,然后我又依赖哪些应用的哪些服务化接口,这些应有服务的质量到底怎样等等,这就是一个服务治理的问题了。所以做了这样的一个链路依赖的整个分析,从这里里面可以看到我提供服务的运行情况,有哪些应用是依赖我的,我又依赖了哪些应用。
( k  \  u: h* t

1 b- M: b& f* M9 ]9 C
1.png
( N. }) c. _7 Y2 P
链路分析还有一个非常关键的作用,稳定性中有一个限流降级系统。关键点就是通过链路分析提炼出核心应用(交易链路)和非核心应用,对于核心应用优先保障,配置的并发数和优先级就高一些,非核心应用就会小一些,如果出现流量特别大的情况,就会考虑把非核心应用降级或限流掉,优先保障核心应用的调用和运行。

( t# @1 j6 D) x8 Z( K5 u
3 j& M) P+ G# @7 R& s
举个简单例子,比如交易相关的购物车下单,如果下单应用依赖了我的服务,那它的优先级就会相对较高,毕竟下单后会马上产生收入,同时可能还有商品评价也依赖我的服务,但这个与交易无关的,那它的优先级就低一些。当我的服务和应用在峰值时(比如大促),策略就是要优先保证交易的应用,其他非核心的应用就降级降掉,或者是并发数限掉,宁可失败但是不可以影响到我整个交易的链路。所以它非常关键的价值就在这里,能够帮助我们梳理清楚核心和非核心的应用,不同的场景采取不同的稳定性保障策略。

" D1 C& h8 O. E$ ~7 U1 b$ o/ z
8 N# c% Y) `9 M( n
原创:赵成

0 T0 w5 Q( Z% `2 F# @2 ?6 L8 W, G, \* Y5 l2 }7 x
; i# P6 p" u7 }8 h* x+ H$ U$ J  T7 n& u

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2019-2-24 13:46 , Processed in 0.216683 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表