微服务转型与DevOps
分享人：郑云龙 睿云智合持续交付产品负责人，在敏捷和DevOps领域有丰富经验的实践，过去作为敏捷和DevOps技术教练向多家大型企业提供咨询和培训服务。 微服务转型与DevOps 1 遗留的现状 在开始微服务和DevOps主题之前，首先看看在过去我的咨询工作中，对于大部分咨询客户而言，企业会邀请外部的顾问来对团队进行改进，最主要的原因都是由于现有的研发体系和产品团队，难以跟上市场的变化，希望通过外部顾问，通过一些手段来提高产品团队的响应力。敏捷实践亦或是DevOps实践最终的目的都是为了能够快速的交付高质量的软件产品。 究其原因，为什么这类客户会有如此大的需求去引入敏捷或者DevOps呢？遗留系统。 历史遗留问题与新问题，新需求的持续混合发酵，导致系统的开发效率无法满足业务的发展需求。所以经常会有如上图这种对话。无论是新的需求，还是遗留的Bug都严重受制于遗留系统 如果从技术角度来看，对于遗留系统最主要的问题包括：高耦合性，底可测试行，代码质量差，圈复杂度高，并且很难对系统进行优化。而这些东西我们都可以称之为技术债。 而这些技术债务的积累最终导致我们的系统越来越难以维护。举个例子，在之前对客户团队进行敏捷技术培训时，尝试在项目中使用TDD，最终的结果是在使用TDD的同时，我们进行了大量的重构，才能保证我们能够顺利的给某一个业务场景添加上相应的测试代码。 而技术债不是一开始就有的东西，对于传统单体架构而言，在项目初期系统通常也是易于开发，易于部署，易于测试的。 随着时间和项目演进，系统的代码量以及复杂度呈指数型增长，最终导致我们整个项目的交付周期越来越长，同时系统很难进行扩展，并且当扩展时所需要的成本也越来越高。 对于新加入团队的成员，也需要花费大量的时间了解业务背景，熟悉应用程序的业务，配置本地开发环境等等。这些看似简单的任务，往往需要花费大量的时间。 同时对于传统单体架构随着时间和项目的演进，尝试引入新技术或者对现有技术框架进行改进的成本和风险也越来越高。 而对于传统的SOA架构？ 如果用直白一点的话来说，就是专注于使用ESB来集成企业内的各个单体应用。而往往导致的结果是两个大的中心化，技术的中心化，以及流程的中心化。 由于EBS通常基于特定的技术栈，并且使用了中心化的标准个规范，使得业务难以根据业务场景去选择合适的技术。 而ESB也往往嵌入了大量的业务流程，所以导致任何服务的修改都需要进过复杂的流程，修改系统的工作量不减反增，维护成本和产品成本也呈非线性增长。 2 什么是微服务架构 通常而言我们对于微服务并没有一个准确的定义，但是我们可以认为，微服务就是我们去以正确的姿势去实现SOA。 对于微服务通常具有以下特性：独立进程，独立部署，独立技术以及独立团队。 对于每一个服务而言都是以开发一个小的独立的应用系统，并且每个服务都是运行在自己的进程中；这些服务围绕业务功能进行构建，并且能够独立的部署和发布；同时服务与服务之间可以使用不同的技术语言以及存储技术；而对于每一个微服务都是由一个充分独立自治的团队进行端到端的管理，从开发，构建，部署，上线运维。并且这些服务之间通常采用一些轻量级的通讯接口包括像Rest API以及消息队列 而对于每一个微服务而言我们都可以根据其不同的业务场景去选择适合的技术，并且这些服务之间可以有不同的发布节奏 除了技术上的去中心化，在团队组织结构上，每一个微服务团队都应该具有和当前业务功能开发所需的全方位技术，及所谓的全功能团队。这些团队围绕着各自的业务管理相关的服务。相比于传统的通过组件的方式拆分团队，微服务团队可以端到端的完成特性交付，减少由于将特性分配给多个团队而导致的沟通问题，系统集成问题，能够更加快速的交付所需的特性，减少等待时间。 同时微服务架构能够帮助我们快速的开辟新的渠道，助力企快速获取市场机会。 刚才谈了很多关于微服务本身的特性，以及能够为我们带来的好处。但是事无好坏，对于任何一家公司和组织，在转向微服务之前都应该明白它为我们带来的潜在的挑战。 微服务化带来的挑战？ 运维的挑战 、质量保证体系、分布式系统的复杂度 首先我们来说关于质量的部分 对于任何传统意义上的测试保障体系，我们通常会通过单元测试，API测试，系统集成测试，以及其他的非功能性测试，诸如性能测试，安全测试等来保证我们软件交付的质量。在敏捷测试实践中我们通常以测试金字塔的方式来评估我们现有系统的自动化测试水平以及合理性。 那在微服务中呢？刚才我们已经说过，微服务是一组独立的去中心化得服务，服务和服务之间必然存在相应的依赖关系。 在这里我们仿照敏捷测试金字塔的方式将微服务的质量保证体系划分为3层:服务内，服务间，以及服务集成。 相比与过去的软件质量保证体系，我们增加了契约测试来保证服务和服务之间的依赖，确保各个服务是能够独立的进行演进升级的。对于契约测试目前包括像Thoughtworks开源的契约测试工具Pact以及Swagger这样的工具都能够帮助我们将契约测试添加到我们的质量保证体系中。 当然对于所有的自动化的质量保证过程，我们都应该将他们纳入到CI流水线中，通过自动化的方式来保证我们每一次代码变更都是能够满足质量要求的。 那对于运维体系而言呢？ 运维体系面临的挑战 1，部署环境的多样性，对于传统团队的Ops人员，他通常都是接触一些固定的技术栈相关的运维和管理工作，但是在服务下，每一个服务都都可能采用不同的技术，数据库，以及中间件。那对于Ops人员而言所需要面临管理和运维的环境的复杂度和难度也随着服务化得进程变得越来越困难 2，对于公司而言从开发，测试到部署上线，我们通常需要使用大量的服务器资源来保证我们各个环节的部署环境需求。举例来讲，在敏捷当中我们通常会有Dev环境，UAT环境，Prod环境去提供软件交付过程中各个阶段的部署需求。但是微服务之后我们可能有几个，几十个甚至几百个不同的服务，而这些服务都需要相应的部署资源，同时如何保证各个阶段的环境一致性问题 3，CI维护成本暴增，在过去我们通常会花费通常一个迭代的时间来搭建我们项目的CI基础设施，但是现在随着服务数量的增加我们管理和配置Jenkins的成本也越来越大 4，除此之外包括，日志，监控，弹性，高可用都是我们在微服务转型过程需要面临的挑战。 如何解决 充分授权团队 在微服务下我们希望每一个团队都是能够充分独立和自治的。但是往往对于企业而言对于基础设施环境的管控要求其实非常高，包括像网络，安全等等。 所以往往对于一个团队想要获取一个服务器资源通常需要复杂的审批以及配置过程。 而通过引入像Rancher这样的轻量级的容器化管理平台，我们可以将底层基础设施的管理问题交给专门的运维团队来进行处理。这些基础设施可以是物理机，IaaS，甚至是容器集群。并且将这些资源按照环境的形式分配给不同的团队，充分授权团队，管理自己的所有的开发，构建与部署环节。 基础设施代码 而对于持续集成流水线，以及持续交付流水线的管理和配置，Jenkins2.0通过Pipeline As Code的方式通过编写DSL来帮助我们实现全面的基础设施及代码的要求。 在代码库当中及包含源代码src，也包含我们的环境准备过程Dockerfile以及环境定义docker-compose.yml. rancher-compose.yml. 同时我们将我们的持续交付流水线也通过Jenkinsfile的形式保存在源代码库中，那么只要我们获取了软件仓库的代码，就能够获取支撑我们软件交付各个阶段的所有物品，包括源代码以及运行时环境。并且对于任何代码或者环境的变更都能够通过持续交付流水线进行持续的验证和反馈 同时Rancher也提供了内置的监控功能：包括主机以及容器。通过Catalog我们也能快速的搭建ELK的日志分析平台以及其他的监控服务。 通过服务容器化，以及引入诸如Rancher这样的容器管理平台。我们可以使我们的研发团队更加专注于软件架构以及环境架构的设计，而将一些其他的运维和管理工作交给容器管理平台来管理。能有效的减少我们在DevOps实践当中的成本，包括人员能力以及自动化能力的要求。 同时对于微服务团队而言，我们基于持续交付流水线能够使软件交付各个阶段的人员能够有效的协同工作，保证我们能够又快又安全的交付软件，每一次代码变更都能够产生一个可工作的软件（当然前提是这些人都是属于同一个团队） 所以对于转型微服务而言，我们需要明白持续交付以及DevOps文化是支撑我们微服务转型的一个重要手段。 我们需要有独立自治的全功能型团队，通过引入虚拟化技术，容器化技技术，以及相应的管理平台来减少我们部署和运维的复杂度。并且通过更加完善的质量保证体系来确保我们的服务能够确实的去支撑我们的软件交付质量。 总结 就像开篇说的一样，“微服务可能是实现SOA的最正确的姿势”，它实际上是我们软件交付领域大量优秀实践的一个集合。同时微服务是不银弹，在引入微服务后我们同时需要面对更多复杂的问题。 通过引入容器化，以及容器化管理平台能够减少我们在转型微服务过程中的大量成本；通过小步尝试，积累经验和能力，能够帮助我们在微服务化转型中走的更加顺畅； 同时根据不同的业务模式选择不同的微服务重构模式能够帮组我们能够在解决现有问题的同时来全面提升我们整个产品的响应力； 最后一张图，简单总结了一下微服务中关于实践与设计模式的概览，希望能够对大家在服务化转型中提供帮助； 最后在准备这次分享的过程中我准备了一些例子，包括Jenkins2的容器化，以及基于Jenkins2和Rancher实现端到端的持续交付过程： https://github.com/yunlzheng/rancher-jenkins2 https://github.com/yunlzheng/jpetstore-6 有兴趣的同学可以进行参考，当中不完善的部分也希望能够提供反馈，能够进行相应的改进。...
Read More