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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 2082|回复: 0

蘑菇街的DeVops实践

[复制链接]
发表于 2018-10-26 16:44:32 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-10-26 16:52 编辑
5 S* ^9 @( Q, `+ ^" @3 V/ i8 ]$ ^4 B0 s, m2 i) W; [6 Q
1.png
蘑菇街技术架构演进过程

$ V( p2 r" i" P, Z- C! V: T. e
* ?, P3 ^+ i, Y5 V  n, i9 H
早期2011年,产品形态是导购,业务量不大的情况下,技术架构选择了相对简单的LNMP架构。通过PHP快速开发,让业务快速运转起来。所以,当时主要以开发人员为主,没有专职的运维的团队。
) g4 u! |( f. {- r5 c4 G4 s
  {$ a3 v8 i2 b. O# L* Y1 @
: M8 {) d% v( j  m
1.png

( F" T4 H" y0 o( z
2013年转型做电商,整个技术架构也没有发生太大地变化,还是以LNMP架构为主。不过在业务从小到大的快速发展过程中,最容易出现瓶颈和问题的是DB的连接、缓存的连接等这种连接数的资源,蘑菇街在这个阶段也遇到的同样的问题,所以架构上的调整,主要是DB中间层和缓存中间层的增加为主,但整体上还是LNMP。+ |4 n( X, o$ u/ u

. I' |* a% ^; y! \) U5 Y! O
, Q  A& {/ k( r4 [4 G

- w4 S1 s( V/ P2 I6 P
1.png

  ^) P) ~7 j2 W4 i
随着业务发展,业务也开始变得丰富和复杂起来,带来的不仅仅是用户量、业务量这种体量上的增长,业务自身丰富度和复杂度也在发生着非常大地变化。对技术上带来的挑战和问题,如下图所示:
. E8 @# x$ f. S0 _  b

7 `3 @3 y9 H! J

3 p! _9 {6 M4 j7 n) }# ~- I
1.png

6 b- ?( i; d. J1 C4 D
可以看到PHP的工程变得异常的臃肿,因为有太多的业务需求需要开发,有太多的开发人员在同时开发,结果短期内PHP的代码工程就造成了局面。
0 ^( I) R/ J& u9 F) T9 ~$ d8 E# r

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

, k5 o9 o! n" N, P# D

2 H# Y) I: s. _/ h2 R
举个例子,对于一个开发的人员来说,如果他要做的功能和需求涉及到其他人的开发的PHP文件,本来这个功能和需求在原有的程序上改就行了,但是因为工程太大了,他可能是没有办法评估清楚说改了这一个文件,对其他的文件、接口和方法会造成什么样的影响,即使能够评估清楚,也很难保证在测试的时候把这些所有的点都能够测试到,根本没这么大的精力。所以就导致很多开发人员会不断的Control C+V,就是宁可是把需要改的文件Copy一份出来,然后在Copy出来的文件上面做开发,原来的功能不动,这样就保证了新需求可以不影响老公能,但是这个状况就会导致进一步加大了PHP工程的臃肿,实际上是一个恶性循环。再就是,如果碰到非改不可的PHP底层的文件和代码,如果评估不到位,就是导致出现各种各样的线上故障。所以,到了这个阶段,PHP代码就很难维护了,反而影响到了需求和版本的迭代速度。
' r/ R6 m2 X* m

7 p* i4 G( d) }8 `
这种情况下应该怎样办呢?需要选择业界比较通用的方案-Java服务化,把大的工程拆分成一个个小的应用,通过服务化框架提供RPC的调用。这个阶段,从PHP转向JAVA,从单一工程转向了分布式服务架构。
( p1 @3 j5 H  P$ K7 z3 W
' ]% A2 ?, l) q* |. G% _

' t6 ?+ C, }7 C" @
1.png
9 {5 y: n* ~& Z1 z  [" w
经过拆分后,整个架构就变成了现在的这个样子。这样看下来整个架构分了很多层,也有很多的细节,乍看上去是比刚才的架构图要复杂一些。但是这样的架构根据条理性,也会让架构里面很多的技术细节都曝露出来,更加便于管理。相对那刚才非常庞大和臃肿的PHP工程,内部的逻辑、方法和接口的依赖等等,是很难梳理清楚的。
' N: \, g& [! m1 {- C
% Y3 A- w' i% E& K% C/ Q

: j* {- \+ a2 h; ]3 L% S6 K6 F
; ^; w  q/ z- K! }/ C! g) S
1.png
# M$ S3 ?" [8 b
下面主要讲做了JAVA服务化的技术转型后,对运维带来的挑战是什么:
) g! X  x( ?( ]5 P1 b+ f) p

3 L7 F2 v. J! ]+ y# O/ m! ?
1、服务化应用的管理问题
& _% k/ C$ ~# ^) p+ c
1.png

$ y1 B$ I8 i! i4 u1 c1 u% [3 }8 ]6 S. b( Y7 U9 Y' c

+ |' |  c. {) g9 p8 s$ R
2、服务化之后的服务治理问题
% @  m! `) S5 `8 S& g
$ z6 u: y1 x& K) e  \, u- y
1.png

* ~4 p) u1 Q9 P" {% W" ?4 }4 o
) u( |  K3 e" Z$ ?/ A4 F
/ X3 G1 C& ?7 b; s! o4 V* N
  运维解决方案和思路

5 Q2 k: r' L' T2 R, i
9 }* ?) F" S$ Y/ i. a: p, W; Z% p
运维基本上要围绕着以下5个目标开展,效率、稳定、成本、体验和安全,重点从效率和稳定这两个方面去讲。
# c7 Z7 A4 ^: @* n8 @/ g; j& W

2 [" t7 ~) w( Q% |7 u0 V
# \, N) a; z' c  A4 x* T' X
1.png

/ s) l. Z% q1 Z7 v- ?! r% n0 C
从0开始应该怎样做,一定要从标准化开始,并围绕标准化展开。关于标准化,不管是做运维平台也好,还是运维体系也好,或者运维系统也好,第一件事要做的一定是做标准化。

$ N  g% E3 k8 t' ]) q# A
. `- M( _  i  z+ [3 s- m
标准化主要做三方面的工作,第一是基础软件及基础设施的标准,主要是操作系统的版本必须统一,内核参数统一,基础设施上,用KVM虚拟化技术将我们的资源做成2C2G、8C16G这样的资源模板,确保资源配置的统一。第二是应用及配置标准化,这个后面细讲。第三是技术架构标准化,技术架构这块分接入层、中间件技术、缓存、DB等,关于技术架构标准化,它的重要性和它的意义在案例中体现出来。
5 u5 N9 q. z( ?# S2 X2 e

) P, F# L! i4 ^) _4 r1 J7 s
, w. e  D* S9 y! f# H
1.png

. B' I% C! g0 C9 E7 b6 Y. S
& r4 t7 j% b9 s( i

, |( k3 N3 u4 V% p+ g
举个例子:

$ P; p4 v- }7 k. X9 S- j* }' x. g5 Q
1.png
8 k; Q# Z: B' ~& y/ S# Y
在做整个运维平台之前,首先将整个系统梳理一下,然后看一下整个系统里面到底有哪些基础环节和软件,应用到底有哪些应用类型。把这些东西一条一条地记下来,然后归纳总结,慢慢的就形成了左边的集团标准化,包括应用管理的标准化。基础服务的标准化,安全的标准化,稳定性的标准化,全部都制定清楚形成文档。

$ }9 E0 }8 f) T2 `

! W' k8 ^  q0 B. t
把标准化的动作做完以后,如果只是纸面上的,那它的威力是没有显现出来的,如果仅仅是以写脚本的方式去管理它,实际上还是有点笨拙,所以再往后就做了这样一个应用配置系统,目的就是把做的标准化沉淀在技术平台上面,可管理,可提供服务。以上的样例就是我针对Java的标准,它的目录,起停的脚本等,通过一个应用模板固化下来,比如实际应用过程中,典型的Java应用,是Nginx+Tomcat的运行方式,那在应用配置管理中,就会有应用模板、基础软件和应用配置文件管理几个模块来管理。
$ n8 p2 j0 Z  [' J

; ~: P- O" i3 W$ @3 o$ x
0 z, L9 q/ K/ t6 o: X2 s% B6 ~) Q9 M
1.png

9 N7 B- d, w; Y8 |+ _: g
以上这部分,是针对标准化,最后通过应用名这个核心将上面所说的这些零散的标准项给串起来,也就是常说的以应用为核心的运维体系。
" U. P/ V, W" P. @) }! m$ [' L( T/ S
9 w' a3 u. U+ z' i* S

7 d+ ^0 d: u0 a  U2 u" J5 F
  案例分享: n; H9 G+ D; y0 h- M

$ s! g; Y7 ~% M& g+ ]4 W8 {5 u- X9 C  F" [( X- d3 w
一、持续交付
5 @" h5 e- |& M6 S% b
3 E) ~# T6 C- A+ f/ f. m7 d
4 J8 @! V3 _: h1 s
做完了标准化及标准化管理以后,遇到的比较棘手的问题就是这么多的应用应该怎样高效发布,这就涉及到持续集成和发布的问题。原来的PHP工程,只要在一个PHP的文件里面把代码写好,把文件推送到服务器上,然后最新的PHP文件就可以直接运行起来了,不用做中间环节的管控,但是对于Java应用来说整个环节就没有这么简单了,Java文件涉及到编译、二方包、三方包依赖,然后编译打包后,将软件包发布到制定的机器上,然后还要重启Java进程,最新的文件才能得以执行,期间还会涉及服务的注册和下线问题等等。

+ G; w6 s0 M' E* \
  B, Y) ~1 Y+ A
从整个过程来说,JAVA整个发布过程是要比PHP复杂很多的。所以为什么要去做持续集成,对于这个持续我的理解是怎样能够把中间环节它的效率尽量提升,减少人为的干预,通过发布的自动化,提升开发和运维的效率。

1 |* o6 ?) T4 c* ~) M

: Q, @8 Q5 l* a* q5 [( h3 h/ E
1.png

) a3 J; Y- Q  r; n+ K2 Y5 D
接下来做的发布系统,提炼一下,发布做的事情就是,将提交后的应用代码,进行编译打包,然后发布到应用对应IP主机的指定目录下,并且做到应用服务的优雅上下线(或者叫做优雅启停)。

  Y8 _+ `9 J& ~
6 \4 ~: t2 }+ [, A. Z6 a6 m0 O; }% l
可以抽象出发布的最重要的三步,如下:' t3 i- K7 M! W5 l0 l" `% F( ~' u$ I9 B

) m$ i$ m! P* T5 K6 U# g, ^9 Z. h# _

  j( ?$ v- k' X3 b* ]& w* b
1.png
下面就分阶段详细描述三个主要环节:
- [$ S- G4 K; ^( S+ I
" H. a: b- p* g/ q/ _  E" o2 X) c
1、代码提交环节(分支合并管理)
  R; ~! o8 m' v* W$ O8 c  }  K

( p3 ~# [' e8 ^$ r2 g
代码管理工具是Gitlab,代码提交过程中最重要的就是对于分支合并的管理(这里又涉及到标准规范的制定),策略示意大致如下:
% w& r2 }6 G- W
- ^) @1 v9 k% K* W
1.png
描述如下:

9 V+ W" ~" o7 J& l4 `) E0 C! z# N$ p
! D. s1 G( u9 K6 e# T- ~  x# ?$ e
1、master分支,跟线上应用代码保持同步,也就是说随时可以发布到线上进行部署运行。
% h/ q5 G  s' S3 g

9 {/ u0 F; r. M- g  \; \
2、开发分支,通常以feature/defect来表示,比如开发一个新的需求,就会以当前master为基线,拉一个feature分支出来进行开发,同一个应用可以同时存在多个feature分支并行开发。
/ n! p3 V2 y% S2 B( U2 C5 c
. \, j3 u' n" i
3、发布分支,以release表示,在发布时会将所有提交集成的代码commit合并,形成release_环境_时间戳为分支名称,比如release_dev_01_29_20_52_10 就代表该分支是在1月29号20:52:10在dev环境发布时创建的临时发布分支。
( g3 [) E% P% j. I

6 C! u; m4 b- u
4、从预发进入线上时,会以当前预发环境的发布分支release_pre_xxxx为基线创建一个release_online分支,作为线上的发布分支,线上发布结束后会把release_online分支合并到master中,这也就保证了发布到线上的代码最终一定会跟master的代码保持一致。

$ g: E# D; {- F. C, b4 \

' Y# E# O3 x/ L) O
2、编译构建环节

9 Z, x! p7 }( A

5 t; L" C( G2 j, Y& N4 u3 F
以上介绍了代码提交环节,下一个环节就是要构建了,以Java为例,构建用到了两个工具,Docker和Maven。Docker主要用来提供一个干净独立的编译环境,Maven作为依赖管理和打包工具。整个构建过程如下:
9 t! x5 J; `' ?# P3 n
1.png
* x1 O  R8 C5 k

" a  |$ j6 n: ~, t) S' q
. J9 j6 K& C0 K9 t' K8 v, W- z
以Java为例,简单描述如下:
1 L  M. E) w+ ?( S0 \

7 {3 z$ \, u7 S. V
1、首先准备好JDK的编译镜像,这个镜像环境与线上环境保持一致,当有新的构建任务进来时,就创建一个对应的Docker实例进行代码编译;
4 P* {" `, u' g2 t
. T0 D3 S( i) g+ a7 C
2、构建任务会根据应用配置管理中的Git地址,将代码clone下来放到指定的编译目录,Docker实例启动后,将编译目录挂在到Docker实例中;
$ X$ f5 {' W% ^; {
: v: V- ]- V" Z
3、对于Java应用,在这个Docker实例环境中,就可以执行mvn package命令打包了,最终会生成一个可发布xxx.war的软件包;

9 a: g% `4 \+ K. c/ B
7 n$ O8 Z& u' |! y. z
4、同样的,对于C++,Go、NodeJs,也会准备好类似的编译镜像,不同的是打包时,对于C++是cmake&make,Go就是go install等等,最终也会生成一个可发布的软件包;

: I' W- D8 m  O
1 v8 N& L$ s: v1 g9 g2 W0 E
5、构建完成后,Docker实例销毁;
# ]! d- t! `* W1 K9 T
! j% g, d& Q" E9 W5 |
这里面Docker发挥了一个很大的作用,就是提供了干净的,互不干扰的编译环境,且对于并发打包的情况,Docker快速创建多个并行的实例出来提供编译环境,使用完销毁,这个效率上的优势也是非常大的。
8 [* [" l! N  k1 B0 X! Z) F# w

' E, `$ \9 w) I; b
6、关于配置管理,当时设计时考虑比较简单,做法是同时做三个配置文件出来,dev_pom.xml,pre_pom.xml,online_pom.xml,分别对应开发、预发和线上三个不同的环境,根据发布的环境不同,将不同的配置文件替换上去。这样做其实可扩展性不够,对于多机房、多分组的情况会有更多的配置文件创建出来,且对于有敏感信息的配置项保密也不够(不过这些配置都已经加密挪到中间件的配置中心了),更好的办法可以考虑采用阿里早已开源的auto-config方案。
/ `' F; g5 A! _8 j* A7 c) l6 g
2 @7 S( r& b8 k0 L. T
3、部署环节
+ Z; k9 _1 t+ n

+ E( e6 _2 K7 j
以上,代码提交和编译构建完成后,就该进入发布到线上的部署环节了,也就是将代码发布到应用对应IP主机的指定目录下,并且能够优雅的上下线应用服务,貌似很简单,但是,看下图:

  C/ F# V! O6 e! W6 h; k) D  o$ p

, a  V; J/ |5 G# Z& @
* a+ P: ~% r; W$ W: Z; A0 w  I
1.png
9 c) d& l( l% ~/ @# ]* Z
这个过程的环节还是比较多的,这些环节内部又会有很多的细节,所以整个部署环节是很复杂的,下面将整体思路介绍一下:
6 N4 o% {3 q1 o1 B
: z) x. }; D3 B5 V; p
0、从CMDB中,拿到应用-主机IP对应关系,然后再从1开始做,后面的过程可以是针对单台机器做,也可以是分批或分组多台机器同时做。(从第0步开始,原因就是上一篇文章里面说的CMDB和应用配置管理的基础要先打好,这个基础没有,下面的环节就无法顺畅地执行);

- X9 Y- z9 @0 V9 G# u% y7 ?" G. t
$ D& |  W0 b# L& B! c2 t
1、检查每台机器上的服务是否正常运行的,如果是正常服务的,说明可以发布,但是服务本身异常,就要记录或跳过了;

% H+ ?5 |6 q; E  V6 I' b0 T

3 ^& B! [! G  C) z3 t& ^
2、下载war包到指定目录(应用的目录信息,应用配置管理又发挥作用了);

& r6 L$ G, y$ t& ]1 r9 O
) M! t  Q7 ~' b" h6 T8 P6 b  r7 j
3、将监控关闭,以免服务下线和停止产生误告警;
$ k: P0 G, U# S, S

  Y& h# y  D: p& ^
4、优雅下线,包含RPC服务从LB下线或Web服务从Nginx下线(如果不提供http服务就不涉及),下线动作均通过API接口调用方式实现;
. I* j* q% O  M+ a! w

. ]1 D6 y2 H2 z7 @- _/ i7 e
5、下线后自动检测无新的流量进入,停止应用,发布代码,然后启动应用(这时应用配置管理里面,启停命令等等就又发挥作用了);
: x$ r. |& ?/ x1 H3 C2 ]

+ Y* \! C( X& i2 D
6、优雅上线,进行健康监测,检查进程和应用状态是否正常,如果全部监测通过,开始上线服务,开启监控;

7 g) A. V$ S1 w  C8 ~+ D

1 t! }, E5 X9 c, j
7、分批发布,这里简单提一下,假设我们一个应用有100台主机,这个时候做发布不可能全部一把停掉,这样服务会中断,但是也不能一台台的做,这样效率又太低,所以我们可以折中分批发,比如可以分5批,每批20台,也可以分10批,每批10台,这样既可以保证在线升级,也可以保证效率能够跟的上。当然复杂一点,还有分组分批,或者按步长分批,第一批5台,第二批10台,后面每批20台等等。示例如下:
& C& d; X% D" f- y( J8 E, b
( W! V' ]3 F7 g# m3 b4 s. [3 i
整个过程下来我们可以看到:
) ^) _  |  q4 }1 j& d0 _7 ~
) @5 J: C3 D8 B& m: l( l0 y
1、基于场景入手,将业务流程梳理细致,做到细分环节,每步自动化,流程串联

, K% o1 O9 r7 c( [4 E

  S+ x9 b' {, e
2、上篇文章提到的CMDB和应用配置管理的内容,在这一部分无时无处不在发挥着基础的作用

" o, X( x" E! A

0 s1 M. m" |3 ?  X, l8 s! T+ \6 W. k& J% ^$ c
效果:NoOps or ITILxf.com" target="_blank" class="relatedlink">DevOps?
# j. R- R) D& I9 f

3 u- V- v, T- ~# Q# m
发布系统上线后,整个过程已经可以做到开发全程自助发布,之前运维还在参与审批,后来审批环节也省略,在发布这个过程中,全流程NoOps。效果如下图所示:
' J( B; _9 v4 l3 [: ~2 j

7 p; z) L  M8 c

. o# W# B( r, h4 _8 X4 W* d$ v- I
1.png
/ [0 s1 p: Q: Z0 C8 ?: `  d1 t8 p
* R) X) n' ?0 q9 o7 }- E. V; [( m

0 P! x: j# u( f. g0 Q
  |) R7 {3 k% b5 W# o, z7 R. p

+ M7 q9 U. {4 A! {, o
- n5 G. s& f5 e: X
二、稳定性建设

" h2 \. W+ z8 U# l1 q
+ E$ Z5 {6 F$ d/ [8 S/ I

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

8 O. [. P. X4 l  v

8 v7 l9 L6 j+ v5 T: l
1.png

2 x! J- _% {; A2 {: H' l
! d4 a% L& q+ O$ j* O
1 m1 }5 s4 P# z0 q" B+ ]8 i% s
主要介绍全链路跟踪系统。首先,为什么要做这个事情?

; l1 v6 X5 A9 a5 X- S0 v/ O
1.png

/ u1 ~3 ~% s6 I0 {

  U* j) ~6 H9 l0 q1 w$ g
: M# a5 ~& [5 @9 H, ]; }5 Q, l2 b) L
这整个的全链路的架构图,在前端的应用上面会做埋点日志,然后通过Kafka放到实时日志集群里面,这样可以快速看到实时的数据,然后对于历史的数据,放到Hadoop里存储。
; w& L4 ?* b: [6 o: z
. B; e2 P9 ~' K3 Q7 r
1.png

# C4 k1 [2 u" F' e* z

$ t  H1 D4 j# s

/ H6 f5 [, S/ g' K4 g; g% s
这里要介绍关键的技术点,其中最关键的就是TraceID,当一个请求到达接入层,会在接入层生成全局唯一的TraceID,由我们自研的Nginx的module实现。然后后续的后端接口或方法调用都会把这个ID带上,这样每一次调完会成都会输出一条日志,把本次请求花费多长时间,调用哪些接口记录下来,这样通过刚才实时的Storm集群就可以计算出整个的实时请求是怎样的。

3 l/ }5 R; O5 h4 w9 D5 Z4 Y
) _7 @7 E2 x) n- o/ W3 b
这里呼应为什么要做技术架构的标准化,这个TraceID是通过Nginx的module生成的,在ID透传的过程中,每一个请求都会从框架层面把这个ID自动带上,业务层面是不用考虑对这个ID单独做处理的,对于http请求,就是自动带上这个参数,对于RPC调用,通过分布式服务框架来处理的。所以接入层架构、分布式架构的这样一个统一的技术栈标准化之后,落地这样的稳定性方案其实就非常顺利了。假设这个标准不统一,Nginx大家有用原生版本的,有用Openresty的,有用Tengine的,或者直接用了Apache,这个module是没法统一定制的,对于分布式的框架,如果有用dubbo,HSF、Thrift的等等,也会无法统一。

) q$ Q3 V* k5 |: f; e
4 g5 A; U( i7 |4 B! H
7 s: ~9 i% V1 n- U7 S+ E
1.png

- Z; e+ w0 s8 d) H" ^" S! J

7 Y7 R/ X; e/ k& q+ I3 W4 g
样例:

0 M/ T8 S# Q6 M! q" _" R$ N& v/ Q

" G* {# ^# |; o4 I, b
1、发现页面慢了到底怎样去做。经常遇到的一个情况就是页面慢了或者是某个页面慢了,根据问题反馈的时间点,可以进行筛选。这个时间段内,请求超过1秒的有哪些,筛选出来后,以TraceId为入口,那接下来整个请求的过程就展示出来了。从这个界面上我们可以很明显的看到,整个请求花了1.5秒,但是下面红色的地方有一个评价的服务,单这个服务接口的调用自己花了1.3秒,肯定是这个服务出了问题,这时候可以大大缩短问题范围的缩小,根据这个IP,直接到这台主机上检查发生了什么问题,后面就可以进入到详细的问题定位阶段。
# t$ o$ b# h3 ^* z. R  |. T
( b- V  g. k* [3 {! f0 E; q
1.png

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

6 k) l" e6 Q2 `! x0 ?9 ~! z

& m5 C, d; j6 a( f0 I
1.png
1 ~) Y- I" V, Q8 E
3、链路分析。一个应用提供出去以后,一个应用又包括了很多服务化的接口,而应用仅仅是成百上千应用当中的一个,这当中有哪些应用依赖了我,然后我又依赖哪些应用的哪些服务化接口,这些应有服务的质量到底怎样等等,这就是一个服务治理的问题了。所以做了这样的一个链路依赖的整个分析,从这里里面可以看到我提供服务的运行情况,有哪些应用是依赖我的,我又依赖了哪些应用。

: m% n, I* @. x7 o2 r6 }+ ]* V- J$ C
- s- a2 ]6 y' [) [; x
1.png

: u: m) c2 [+ u/ H  [. Z
链路分析还有一个非常关键的作用,稳定性中有一个限流降级系统。关键点就是通过链路分析提炼出核心应用(交易链路)和非核心应用,对于核心应用优先保障,配置的并发数和优先级就高一些,非核心应用就会小一些,如果出现流量特别大的情况,就会考虑把非核心应用降级或限流掉,优先保障核心应用的调用和运行。
5 q: m' y" s  h. O
' Z0 A: F7 W7 `5 J
举个简单例子,比如交易相关的购物车下单,如果下单应用依赖了我的服务,那它的优先级就会相对较高,毕竟下单后会马上产生收入,同时可能还有商品评价也依赖我的服务,但这个与交易无关的,那它的优先级就低一些。当我的服务和应用在峰值时(比如大促),策略就是要优先保证交易的应用,其他非核心的应用就降级降掉,或者是并发数限掉,宁可失败但是不可以影响到我整个交易的链路。所以它非常关键的价值就在这里,能够帮助我们梳理清楚核心和非核心的应用,不同的场景采取不同的稳定性保障策略。
! N& K$ Q) f0 v, X$ q
  q5 u9 H  H0 y2 v- d" O
原创:赵成
( p+ J5 y; b1 b6 [; `

( d: N$ J) E, k3 s' a+ K9 ]4 }, v% p, p9 Y6 h; I& f




上一篇:DevOps金融行业转型案例:Capital One两年实现蝶变
下一篇:DevOps 道法术器,完整版立体化实施框架
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 04:06 , Processed in 0.123675 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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