分享到社交媒体:

本文首发于「BOB官方网站」,转载请参考版权声明


01 食之无味,弃之可惜

在企业级应用的季度或月度发布被认为是领域最佳实践的时候,应用部署到生产环境之前维护一个完整的环境进行集成BOB官方注册是非常必要的。但是,集成BOB官方注册环境和集成BOB官方注册本身有着如下的问题:

  • 环境本身脆弱,而且通常存在手动配置部分,环境维护成本很高;
  • 环境因素导致集成BOB官方注册不稳定、不可靠、反馈慢,BOB官方注册失败不易定位问题,同时还会重复BOB官方注册隔离组件已经测过的功能。

集成BOB官方注册成为了持续交付的瓶颈,犹如鸡肋。因此,最新一期(2017年第16期)ThoughtWorks技术雷达建议企业暂缓搭建企业级集成BOB官方注册环境,而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约BOB官方注册、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。

02 断舍离之技术可行性

下面分别介绍技术雷达建议的这四项技术,以及在没有集成BOB官方注册的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。

1. 消费端驱动的契约BOB官方注册

消费端驱动的契约BOB官方注册是微服务BOB官方注册的重要组成部分,主要用来覆盖两两服务之间的契约关系,下面举个例子来说明什么是契约BOB官方注册以及契约BOB官方注册与APIBOB官方注册的区别。

家里有个插座,买电器的时候需要考虑插头跟插座是能配对的,也就是说插座和插头之间需要有契约。

这里的契约BOB官方注册就是插座跟插头的配套性BOB官方注册,包括

  • 三相/三头还是两相/两头的;
  • 电压是220V还是 110V;
  • 插孔的形状:英式?中式?
  • 等等

APIBOB官方注册:对于插座本身功能的BOB官方注册,需要覆盖

  • 插座能够正常通电;
  • 电压是预期的220v;
  • 接地的插孔真的能够接地
  • 等等

也就是说APIBOB官方注册需要BOB官方注册API本身功能的各个方面,而契约BOB官方注册重点在覆盖API调用的格式、参数数量、参数类型等,不一定需要涉及API本身的功能和具体的数据。

更多关于消费端驱动的契约BOB官方注册,请参看文章《Consumer-Driven Contracts: A Service Evolution Patter》。

2. 发布与部署解耦

部署,就是把组件或者基础设施部署到生产环境,不对用户可见,不会影响业务和用户的使用。发布,则是将部署的组件让用户可见,对业务会产生影响。可以通过采用Feature toggle的方式实现部署与发布的解耦,做到持续部署和可控制的发布,减少组件改变带来的风险。这样,产品经理可以根据业务需求灵活控制发布给最终用户的功能组件,帮助企业业务价值最大化。

3. 关注平均恢复时间

先看这样两种情况,思考哪种更好:

1)系统宕机次数很少,可能每年也就一到两次次,但是恢复能力很弱,一旦宕机,得花至少24个小时恢复正常;
2)系统宕机频率较高,不过每次宕机都能快速恢复,用户甚至感觉不到。

对于第一种,平均失败间隔很长,但是一旦失败对用户的影响不言而喻;第二种虽然有频繁的失败,但是平均恢复时间很短,用户体验不受影响,当然是第二种更好。

传统的Ops团队比较关注失败发生的频率,随着持续交付和监控技术的发展,快速恢复成为可能。不用担心错误、失败的发生,而是利用对这些错误和失败的监控和分析,让系统做到快速恢复,可以省掉一些复杂的集成BOB官方注册,也可以减少无处不在的安全攻击的影响。

4. 生产环境下的QA

生产环境是真实用户使用的环境,通常都不能跟BOB官方注册环境那样可以在上面直接BOB官方注册产品的功能,不能简单的把BOB官方注册环境所用的的QA技术直接后延到生产环境,而其中一项在生产环境使用的技术就是监控。采用监控技术来获取生产环境的信息,对其进行分析,然后优化开发、BOB官方注册过程,同时优化企业业务。更多关于生产环境下QA的内容,请参看文章《生产环境下的QA

对上面四种技术的解释,我们可以看到:契约BOB官方注册是对持续独立部署有帮助的,监控技术则是缩短平均恢复时间和做好生产环境下的QA共同的关键技术之一。接下来主要分享项目在围绕契约BOB官方注册和日志监控这两块所做的实践,一起来看系统级集成BOB官方注册的断舍离该如何实现。

03 断舍离之项目实践

项目是一个开发了七八年的老项目,团队对集成BOB官方注册也是进行了多次的调整,经历了“七年之痒”后依然觉得是鸡肋:

  • pipeline上执行非常不稳定,总是“随机挂”,不能真实反映问题;
  • 系统复杂,集成BOB官方注册自然也不简单,每次顺利执行的时间都需要半个小时以上,何况还有很不稳定的情况,最严重的时候导致QA超过一周拿不到包部署;
  • 通过集成BOB官方注册发现的应用程序的缺陷半年也难得出现一个;
  • 随着系统逐渐变得复杂,集成BOB官方注册维护的成本也不断增加。

可以看出,集成BOB官方注册已经严重阻碍了项目持续交付的进行,不得不对其断舍离了。

1. BOB官方注册策略调整

断舍离的第一个部分是从集成BOB官方注册本身入手,调整BOB官方注册策略。步骤如下:

1)不再添加新的功能层面的自动化BOB官方注册,原有的集成BOB官方注册部分能用底层的UT、APIBOB官方注册覆盖的尽量下移;
2)UT和APIBOB官方注册不能cover的服务间的契约关系通过增加契约BOB官方注册来保证;
3)从CI上摘掉原来的集成BOB官方注册,加速pipeline出包,然后添加SmokeBOB官方注册到QA环境执行;
4)不管是在BOB官方注册环境还是生产环境发现缺陷,则添加对应的BOB官方注册。

整体策略调整思路是根据BOB官方注册金字塔的结构进行调整,把BOB官方注册尽量往下层移,但并没有全部去掉集成BOB官方注册,只是缩减到非常关键的路径覆盖,最终BOB官方注册结构调整如下图所示:

2. 日志监控、分析和优化

没有了Pipeline上的集成BOB官方注册,直接上到QA或者prod环境,那么加强日志监控变得尤其重要。因此,断舍离的第二个部分是日志的监控、分析和优化。

日志数据采集

项目使用的日志分析工具是Splunk,使用该工具从下面几个方面来着手采集日志数据:

1)在Splunk上设置日志监控的Dashboard,主要用来监控API的请求失败、错误的日志,还有API执行时间等性能相关内容。如下图所示:

2)设置预警邮件提醒:对于一些存在严重性能问题的API请求,通过邮件的方式进行预警提醒,如下图:

3)主动查找错误日志:对于一些生产环境用户反馈回来的问题,通过主动查找错误日志的方式去定位。
4)前面的几个机制同样应用于QA和Staging等BOB官方注册环境,以通过日志分析尽量提前发现问题。

日志数据利用

利用前面几种方式采集到的日志数据,从下面几个方面进行分析和优化:

1)发现和定位系统功能问题,分析系统用户的行为习惯,优化业务;
2)发现和定位安全、性能等非功能问题,进行修复和优化;
3)发现和分析日志记录本身的不足,规范日志记录,从而进一步增强日志给问题诊断带来的帮助,形成良性循环。规范日志记录主要涉及这些点:统一日志输出路径、统一日志记录格式、清晰定义日志级别,并且把添加必要日志作为story开发流程的一部分,QA会参与日志评审。下图是Splunk里看到的项目最新优化的日志记录格式:

项目对集成BOB官方注册断舍离才刚刚开始,正在不断摸索着前进,目前能看到的最直接的影响是pipeline出包明显加快,由以前的好几天出不来一个包变成一天能出好几个包。最让人振奋人心的是本周刚刚发生的事情:前一天下班前报的bug,第二天上午就已经修复出包可以BOB官方注册了。

04 写在最后

系统级集成BOB官方注册虽然有各种问题,不一定会因为集成BOB官方注册挂掉而发现很多问题,前面也讨论了断舍离的可行性,分析了项目断舍离的实践,但集成BOB官方注册并不是用来发现问题的,而是一道对质量把关的屏障,关键路径的必要BOB官方注册是不可替代的。因此,我们提倡减少集成BOB官方注册的数量,合理调整各层BOB官方注册的比例。

系统级集成BOB官方注册的断舍离需要团队有持续、递进、稳定的交付能力,需要保证用户不会受此影响,企业业务能够正常运转。系统级集成BOB官方注册的断舍离过程不是一蹴而就的,凝结在集成BOB官方注册上的心血也不是那么容易放弃的,需要很多的平衡和取舍,并在整个过程中要不断的关注系统的质量和风险,及时作出相应的调整。


本文首发于「BOB官方网站」,转载请参考版权声明

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注