学习微服务系列（三）：springboot+页面前后端分离与RESTFUL风格接口编写
学习微服务系列（四）：springboot服务gateway网关
学习微服务系列（五）：springboot微服务使用nacos作为注册中心
学习微服务系列（六）：springboot微服务使用nacos作为配置中心
学习微服务系列（八）：springboot服务分布式事务及解决方案
学习微服务系列（九）：springboot服务接口安全认证设计
学习微服务系列（十）：springboot微服务分布式异步消息通信
现在的互联网公司都是采用小步快跑的项目迭代模式进行开发，那么项目的交付速度、更新频率是衡量一个公司能力的重要指标，如果一个传统的软件企业开发一个系统半年或者一年才交付的一旦面临以周或天为单位交付的情况那就很可能会被淘汰。比如一个公司开发一个软件刚开始是非常有市场竞争力的，产品也是非常超前的，但是一年以后软件才研发完才上市，这样那就早已经失去了优势，因为市场的热点早已经发生了改变，竞争对手公司早已经发布多个版本并且占领了市场。这样我们就十分需要一个敏捷开发快速迭代的流程来帮助我们快速实现反馈，验证，交付，运营。
曾经与现在
单体架构开发上线
开发人员熬夜变更，在流量重新恢复之前完成。在此过程中开发人员要抗住各种压力，聚精会神，不能写错一行命令。结果可能是不尽如人意，各种故障层出不穷。开发人员怪运维人员写错命令，运维人员怪开发人员留了好多“坑”，出故障了怪测试人员测试不充分，测试人员怪开发人员“留坑”太多，时间太紧没法全找出。
- 需要大量的重复性劳动
- 加长了修复问题的时间
- 项目迭代缓慢往往新增一个小功能就需要将整个项目进行修改
- 项目质量较低 有个图特别的形象，给大家看一下：
可持续集成开发上线
服务好架构+可持续集成就好比整个汽车可以分解成：底盘、车身、驾驶舱、发动机舱、驱动部分等。而每一部分都是由很多小的零件块组成。组装过程也是先完成：底盘、车身、驾驶舱、发动机舱、驱动部分等的拼装，然后再用这些大部件，进行整车组装。而底盘、车身、驾驶舱、发动机舱、驱动部分的组装之间又不会相互干扰。 持续集成流程：
给我们带来的好处有：
- 降低交付周期。
- 通过自动化工具实现设计、开发、测试、发布、运维各个阶段的重复性工作。
- 通过工具实现标准化、规范化，降低出错概率。
传统单体与分布式服务对比
持续部署流水线
《持续交付》一书中对部署流水线的定义是：部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。软件的每次变更都会经历一个复杂的流程才能发布。
Cloud Native
Cloud Native是一系列架构、研发流程、团队文化的最佳实践集合，以此支撑更快的创新速度、极致的用户体验、稳定可靠的用户服务、高效的研发效率。他需要一些列的软件和组织、文化、技术的共同变革。其实可以理解支撑Cloud Native的集合有3个点。
从研发流程的角度来讲，自动化的研发环境是Cloud Native的基础。因为使用云作为基础设施，已经具备基础的自动化能力，可以达到自服务的要求，流程中应该尽量减少沟通人员的规模，尽量减少测试及运维对开发的协助，最好由全栈工程师独自、快速完成交付。保持各个环境一致，容器使得这一点更容易实现。
微服务
微服务架构是Cloud Native的重要组成部分。微服务架构给我们带来什么样的收益以及我们怎么进行微服务架构大家可以参照系列专栏的前几篇文章有详细的描述。在这就不过多的进行介绍了。
自服务敏捷基础设施
实际上，部署、运维是非常浪费时间及精力的，并且非常重要，不能出错。如前所述，Cloud Native的基石是微服务架构、敏捷基础设施及公共基础服务。敏捷基础设施到底能给我们提供什么呢？无须运维人员，全部自动化，通过容器封装环境，开发人员可以直接将所有软件和依赖直接封装到容器中，打包成镜像，生产环境直接部署镜像，通过容器实现开发、测试、生产环境的一致。我们看看在Cloud Native下主要涉及的相关技术有哪些：
- 基于容器的敏捷基础设施。容器的意义在于相对于物理机性能损失不大的情况下，为我们提供了标准化的运行环境，能够把复杂的配置封装到镜像中。特别是在微服务架构中，服务数量较多，上线频繁，为了保证高可用，需要轻量级的隔离机制，当流量变化时，需要快速伸缩。
- 基于公共基础服务的平台化。包括监控服务、缓存服务、消息服务、数据库服务、负载均衡、分布式协调、分布式任务调度等。
- 监控告警服务。监控告警永远是系统运维最重要的话题。要实现快速交付，就必须在自动化测试、灰度发布、监控告警、故障定位及修复上面下功夫。其中监控能让系统处于可控的情景中，故障出现时，快速发现并报警，可以有效提升可用性。
- 分布式消息中间件服务。通过分布式消息中间件解耦。同步调用是一种强依赖，而异步调用是一种弱依赖，很多场景下强依赖会导致彼此互相影响，可用性下降。
- 分布式缓存服务。常用的我们都采用redis作为缓存的中间件技术。
- 分布式任务调度服务。分布式任务调度是非常常见的一个公共服务，特别是在比较复杂的大型分布式系统中。在分布式架构中常见的分布式任务调度框架比如xxl-job。
归根结底就是需要做这3个事：
达到的最终目的：
通过持续交付能够给我们带来如下优势：
- 降低交付周期
- 避免重复性工作
- 降低出错概率 实现持续集成需要做到如下几点：
- 以代码为准，代码统一管理
- 单元测试覆盖率高
- 自动化功能测试和集成测试
- 代码提交意味计入测试环节
- 通过配置中心实现功能开关
- 持续集成工具可对代码检测，测试覆盖率，代码重复率等
涉及相关技术
- 代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
- 构建工具：Ant、Gradle、maven
- 自动部署：Capistrano、CodeDeploy
- 持续集成（CI）：Bamboo、Hudson、Jenkins
- 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
- 容器：Docker、LXC、第三方厂商如AWS
- 编排：Kubernetes、Core、Apache Mesos、DC/OS
- 服务注册与发现：Zookeeper、etcd、Consul
- 脚本语言：python、ruby、shell
- 日志管理：ELK、Logentries
- 系统监控：Datadog、Graphite、Icinga、Nagios
- 性能监控：AppDynamics、New Relic、Splunk
- 压力测试：JMeter
- 消息总线：ActiveMQ、SQS
- 应用服务器：Tomcat、JBoss
- Web服务器：Apache、Nginx、IIS
- 数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库
- 项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
在DevOps中开发人员要做点啥
- 持续的学习
- 了解整个流水线所应用的技术和工具，比如：docker，k8s，Jenkins，Zabbix等
- 习惯进行Code Review
- 提高代码质量
