开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：消息队列和应用工具产品体系-微服务架构引发的问题】
课程地址：https://edu.aliyun.com/course/3112075/lesson/19036
消息队列和应用工具产品体系-微服务架构引发的问题
内容介绍：
微服务架构对系统的可用性带来的影响
一．快速迭代导致功能性测试周期大大缩短
二．较小的业务单元需要更强大的调用链路跟踪
一．快速迭代导致功能性测试周期大大缩短
微服务架构倡导小团队、小服务，快速迭代开发的模式，在这种模式中，一个迭代周期的平均时间只有几周甚至几天，这种情况下能留给 QA 人员的测试时间也变得很短，测试人员很难像瀑布式开发流程中那样，执行单独且完成完善的整体测试流程。
而如何在短时间内完成测试并保证质量，就对 QA 人员和整个开发模式提出了新的挑战。因此业界也对软件测试提出了很多新的思路，其中比较有代表性的是 Kent Beck 著作《测试驱动开发》，简称 TDD，就是下面图中的这本书。
TDD 最主要的思想就是在软件设计之初就开始进行测试用例的编写，对开发人员提交的代码进行快速的验证，从而达到以测试来驱动整个研发过程的。
上图中的八个状态表示了 TDD 倡导测试在软件迭代中期中的八个阶段。首先在本次迭代的功能确定开始，就开始编写测试用例，然后通过测试用例来验证开发者每次提交的代码。刚开始时开发者提交的代码无法通过测试，通过不停的迭代和修改，测试的通过率越来越高，直到全部通过测试。接着开发者在对内部的流程进行重构，来提高代码的运行效率，并完善架构。
通过此流程可以发现 TDD 思想在实践过程中，测试所用的集合要不断的执行测试和验证工作，因此这就需要利用更加强大的自动化测试工具才能达到持续验证的目的。
二．较小的业务单元需要更强大的调用链路跟踪
互联网业务的高速发展带来了业务逻辑的日趋复杂，越来越多的网站采用分布式部署架构，同时 Spring cloud 、double 等微服务框架不断成熟，分布式架构已经成为互联网业务的主流软件架构。分布式的微服务架构在开发效率上具备先进性，但是也给传统的监控、运维、诊断技术带来了巨大挑战。
以淘宝网的分布式架构微服务实践过程来看，遇到的挑战主要有：
1. 定位问题难，客服人员接到用户反馈后，会交给技术人员排查解决，而微服务架构中，网站的请求通常要经过多个服务节点才能返回结果，一旦请求出现错误，通常要在多台机器上反复翻看日志才能初步定位问题。对简单问题的排查也常常涉及到多个团队的反复沟通，浪费大量的开发精力。
2. 发现瓶颈难，当用户反馈网站出现卡顿的现象时，很难快速发现瓶颈在哪里，是用户终端到服务端的网络问题，还是服务端负载过高导致响应变慢，或是数据库压力过大，即使定位到了导致卡顿的环节，也很难快速定位到代码层的根本原因。
3. 架构梳理难。在业务逻辑变得越来越复杂后，很难从代码层梳理出应用所依赖的数据库、HTTPAPI、缓存等下游服务和资源，及外部调用。业务逻辑的梳理、架构的制度和容量的规划也变得更加困难。以双11促销活动的准备为例，成百上千的服务，每个服务能承受最大的并发是多少？需要为每个应用准备多少台机器，出现问题如何快速的定位？
这些信息通过传统的人工运维和人工观测的方法都很难获得准确数据，因此就需要通过新的应用工具进行诊断和跟踪。
