1
遗留的现状
在开始微服务和DevOps主题之前，首先看看在过去我的咨询工作中，对于大部分咨询客户而言，企业会邀请外部的顾问来对团队进行改进，最主要的原因都是由于现有的研发体系和产品团队，难以跟上市场的变化，希望通过外部顾问，通过一些手段来提高产品团队的响应力。敏捷实践亦或是DevOps实践最终的目的都是为了能够快速的交付高质量的软件产品。
究其原因，为什么这类客户会有如此大的需求去引入敏捷或者DevOps呢？遗留系统。
历史遗留问题与新问题，新需求的持续混合发酵，导致系统的开发效率无法满足业务的发展需求。所以经常会有如上图这种对话。无论是新的需求，还是遗留的Bug都严重受制于遗留系统
如果从技术角度来看，对于遗留系统最主要的问题包括：高耦合性，底可测试行，代码质量差，圈复杂度高，并且很难对系统进行优化。而这些东西我们都可以称之为技术债。
而这些技术债务的积累最终导致我们的系统越来越难以维护。举个例子，在之前对客户团队进行敏捷技术培训时，尝试在项目中使用TDD，最终的结果是在使用TDD的同时，我们进行了大量的重构，才能保证我们能够顺利的给某一个业务场景添加上相应的测试代码。
而技术债不是一开始就有的东西，对于传统单体架构而言，在项目初期系统通常也是易于开发，易于部署，易于测试的。
随着时间和项目演进，系统的代码量以及复杂度呈指数型增长，最终导致我们整个项目的交付周期越来越长，同时系统很难进行扩展，并且当扩展时所需要的成本也越来越高。
对于新加入团队的成员，也需要花费大量的时间了解业务背景，熟悉应用程序的业务，配置本地开发环境等等。这些看似简单的任务，往往需要花费大量的时间。
同时对于传统单体架构随着时间和项目的演进，尝试引入新技术或者对现有技术框架进行改进的成本和风险也越来越高。
而对于传统的SOA架构？
如果用直白一点的话来说，就是专注于使用ESB来集成企业内的各个单体应用。而往往导致的结果是两个大的中心化，技术的中心化，以及流程的中心化。
由于EBS通常基于特定的技术栈，并且使用了中心化的标准个规范，使得业务难以根据业务场景去选择合适的技术。
而ESB也往往嵌入了大量的业务流程，所以导致任何服务的修改都需要进过复杂的流程，修改系统的工作量不减反增，维护成本和产品成本也呈非线性增长。
2
什么是微服务架构
通常而言我们对于微服务并没有一个准确的定义，但是我们可以认为，微服务就是我们去以正确的姿势去实现SOA。
对于微服务通常具有以下特性：独立进程，独立部署，独立技术以及独立团队。
对于每一个服务而言都是以开发一个小的独立的应用系统，并且每个服务都是运行在自己的进程中；这些服务围绕业务功能进行构建，并且能够独立的部署和发布；同时服务与服务之间可以使用不同的技术语言以及存储技术；而对于每一个微服务都是由一个充分独立自治的团队进行端到端的管理，从开发，构建，部署，上线运维。并且这些服务之间通常采用一些轻量级的通讯接口包括像Rest API以及消息队列
而对于每一个微服务而言我们都可以根据其不同的业务场景去选择适合的技术，并且这些服务之间可以有不同的发布节奏
除了技术上的去中心化，在团队组织结构上，每一个微服务团队都应该具有和当前业务功能开发所需的全方位技术，及所谓的全功能团队。这些团队围绕着各自的业务管理相关的服务。相比于传统的通过组件的方式拆分团队，微服务团队可以端到端的完成特性交付，减少由于将特性分配给多个团队而导致的沟通问题，系统集成问题，能够更加快速的交付所需的特性，减少等待时间。
同时微服务架构能够帮助我们快速的开辟新的渠道，助力企快速获取市场机会。