技术制胜|中生代技术成都线下活动第一期总结

2016年4月23日下午13:30-17:00，中生代技术成都线下第一期交流活动在成都天府软件园创业场举行。此次线下交流活动共有46位小伙伴参与。活动中，分别由诺基亚成都研发中心研发经理刘朋分享《从DevOps到BDD》；蚂蚁金服成都研发中心技术专家陈显铭分享《支付宝全链路压测》；右军、张莹、王友强，刘朋、张林等一起探讨了技术管理相关话题。

主题一：从DevOps到BDD

  DevOps（英文Development和Operations的组合），是一组过程、方法与系统的名称，用于促进开发（应用程序/软件工程）、技术运营和质量保证（QA）部门之间的沟通、协作和整合。目标在于建立一种文化和环境，从而使软件的开发、测试、发布能够更快、更频繁、更可靠。它的出现是由于软件行业日益清晰的认识到：为了按时交付软件产品和服务，开发和运营必须紧密合作。

        我们可以将DevOps看作开发（软件开发）、技术运营和质量保障（QA）的交集。传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的不止是软件部署。它是针对这几个部门间沟通与协作问题的流程和方法。

        需要频繁交付的企业可能更需要对DevOps有一个大致的了解。DevOps的引入能对产品交互、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在信息的“鸿沟”-例如运营人员要求更好的可能性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

        以下几方面因素可能促使一个组织引入DevOps：
         1、使用敏捷或其他软件开发过程与方法。         2、业务负责人要求加快产品交付的速率。         3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍。

         4、数据中心自动化技术和配置管理工具的普及。

        DevOps经常被描述为“开发团队和运营团队之间更具协作性和更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能够得到降低。

        DevOps的关键词：反馈系统、更快的反馈。既然错误是不可避免的，那么我们还不如就让错误发生的反馈速度更快。

        反馈如何更高效、更精确？反馈很显然是系统输入的一部分，因此是非常重要的资产(capital)。那么为什么我们对反馈往往是忽略的，比如UT？ 原因就在于：反馈和输入必须是同质的，而不是异质的。

        如上图所示，TDD就是为了更快速、更高效的获得从code到build到UT的反馈。 CI(持续集成)就是为了更快地到从code到build，到test的反馈。 ATDD就是为了更快的得到从plan到code到build，到test的反馈。

        BDD（Behavior Driven Development）行为驱动开发，是一种敏捷软件开发技术，它鼓励软件项目中的开发者、QA、非技术人员或商业参与者之间的协作。

       BDD的一个关键，但是看似微小的改变就是在描述测试点的时候，用“should”替代了“test”。也就是说，你可能会听到“预期的行为是什么？”而不是“我应该测什么？”。

        总结：

1. DevOps的出现就是为了解决软件开发周期中各个参与方的脱节问题。

2. DevOps的目的就是为了更快得到反馈。为了更快的得到反馈，输入和反馈就需要有同质的语言。

3. ATDD、BDD、TDD的共同点都是强调利用客户的视觉描述系统的行为(behavior)。

4. ATDD的关键是Acceptance criteria描述behavior。

5. BDD关键是利用具体的Example描述behavior。

6. BDD相关工具JBehave、Cucumber。

主题二：电商全链路压测

        性能是驱动技术演进的重要动力之一。在多应用分布式服务集群化时代，就像上图展示的架构一样，看上去觉得已经很棒了。其实伴随整个集群应用服务节点的增加，数据库资源的瓶颈将是最早暴露出来的问题。
        处理网络瓶颈的一种方式：使用点对点方式替换Proxy方式，将集中的系统流量分散到每一个服务节点上。        处理数据库连接瓶颈的两种方式：引入数据库代理层和应用单元化部署。如下图：

应用及优化的几个发展趋势：

1. 单应用到多应用。

2. 集中式部署、分布式部署、单元化部署。

3. 单机房部署、多机房部署、异地多机房部署。

4. 单系统优化、结构性优化。

        传统压测模式1：线下性能实验室压测。在线下模拟相关的测试环境。        环境问题永远困扰你：

(1)、依赖系统可能缺失；

(2)、数据可能缺失；

(3)、使用的机器、网络和DB可能都不一样。

        优点：

(1)、可以实现快速的压测；

(2)、压测场景可以自己制定；

(3)、可以进行稳定性测试和链路性性能回归。

         缺点：

(1)、仿真度不高；

(2)、环境部署复杂；

(3)、多个压测任务一般不能并行。

传统压测模式2：线上引流压测。通过流量调度器、负载均衡器、代理等方式将线上真实流量引入压测环境进行测试。

         优点：

(1)、真实的业务场景测试；

(2)、可以按需缩容；

(3)、可以快速回滚。

         缺点：

(1)、对链路节点压测不了（DB流量可能不够，网络节点）；

(2)、很难进行超出业务流量的压测；

(3)、很难评估链路性能。

        线上真实环境压测：        优点：(1)、高仿真度；(2)、按需压测流量。        缺点：(1)、实现成本可能会微高。
        详解全链路压测：

1. 技术选型分析：

   (1)、价值。

   (a)、高仿真压测环境；

   (b)、按需的压测能力（比如应对压测）;

   (c)、链路瓶颈识别能力。

   (2)、原则：

   (a)、安全；

   (b)、有效。

   (3) 整体目标：

   (a)、不干扰正常业务；

   (b)、不造成业务错误；

   (c)、操作简单、随时随地；

   (d)、高仿真性，可以对链路上的节点进行压测（网络节点、系统、DB、Cache）；

   (4)技术目标：

   (a)、正常业务和压测业务的隔离型；

   (b)、压测流量的快速回退能力；

   (c)、压测流量的动态调度能力；

   (d)、不侵入业务，不增加复杂度。

2. 技术关键点分析：隔离方案，单个系统场景的情况。

   (1)、为什么要Copy一份真实数据库的表结构？压测隔离，本质上是要做压测数据的隔离；采取新建一套表的方式是基于：简单、安全综合考虑。

   (2)、只有DB才需要隔离吗？理论上，任何存储介质都需要隔离。

   (3)、怎么实现数据路由？压测用户uid倒数第二位（A-Z对应0-9的sharding规则）

3. 技术关键点分析：隔离方案，系统链路场景的情况。

   (1)、交易查询系统怎么感知是压测流量，进行进行数据路由？

   (2)、对全链路压测流量的识别需要具有传递性，如果识别丢失则会造成数据路由失败。

4. 技术关键点分析：隔离方案，有外围依赖的情况，对外部服务进行Mock。

   (1)、优点：简单；

   (2)、缺点：外围链路怎么压测？

5. 技术关键点分析：隔离方案，异步化怎么处理。

   (1)、异步化有哪些场景？(a)、定时任务；(b)、消息；(c)、队列 等。

   (2)、异步化带来什么问题？(a)、链路压测的标识不能丢失，否则数据路由会丢失。解决：定时任务等异步发起者需要有能力把压测标识进行传递的能力。

6. 全链路压测两个技术难点。

   (1)、每个应用系统对压测数据的路由能力。框架对技术解决方案的支撑能力：支付宝数据中间件zdal根据压测标识做统一的数据路由。

   (2)、压测标识的链路传递性。支付宝分布式服务框架可以支持。怎么实现？

           1、如果是WS服务，使用ws-header传递上下文。

           2、如果是自定义协议，可以把上下文作为协议的一部分传递。

主题三：技术管理话题探讨

所有讨论话题如下：

        1、业务的实现、很多解决方案，每个人对知识的理解成都不一样，造成技术争吵，做技术的有点傲   气，不认同其他人的观点，该怎么解决？        2、技术团队管理者如何引入新技术？        3、如何在团队推行code review？        4、技术管理者和团队是否应该在私下有很多私生活的接触？        5、怎么更好的留住团队里面的核心人才？        6、团队或者部门中如何处理老、中、青同事的关系以及工作之外的关系？        7、对团队生产力和成熟度如何进行评估？        8、如果在团队中遇到技术比较好，但是不服管理者的情况怎么处理？        9、如何做到对专业技术人员的合理管理和成果界定？        10、每个开发人员对需求的实现都有不同的理解，如何尽可能提高开发人员对开发任务的理解同产品经理的需求保持一致的水平？（请点击阅读原文大卫张33总结的技术管理话题文章 - 创业杂谈：创业团队怎样解决留人与考核问题？）

本次活动全体小伙伴合影

鸣谢

此次活动特别鸣谢天府软件园创业场的大力支持！

感谢机械工业出版社，清华大学出版社对中生代技术的图书赞助！

『中生代技术』连接技术大咖的桥梁促进科技技术的交流微信号：freshmanTechnology

中生代每周三中生代微信群直播，加群请关注公众号，回复『中生代』