基础设施|终于有人把云原生讲明白了( 三 )

微服务具备灵活部署、可扩展、技术异构等优点，但需要一定的技术成本，而且数量众多的微服务也增加了运维的复杂度，是否采用微服务架构需要根据应用程序的特点、企业的组织架构和团队能力等多个方面来综合评估。
3. 服务网格
随着微服务逐渐增多，应用程序最终可能会变为成百上千个互相调用的服务组成的大型应用程序，服务与服务之间通过内部或者外部网络进行通信。如何管理这些服务的连接关系以及保持通信通道无故障、安全、高可用和健壮，就成了一个非常大的挑战。服务网格（Service Mesh）可以作为服务间通信的基础设施层，解决上述问题。
服务网格是轻量级的网络代理，能解耦应用程序的重试/超时、监控、追踪和服务发现，并且能做到应用程序无感知。
服务网格可以使服务与服务之间的通信更加流畅、可靠、安全，它的实现通常是提供一个代理实例，和对应的服务一起部署在环境中，这种模式我们称为Sidecar模式，Sidecar模式可处理服务之间通信的任何功能，比如负载均衡、服务发现等。
服务网格的基础设施层主要分为两个部分，控制平面与数据平面，如图1-1所示。控制平面主要负责协调Sidecar的行为，提供API便于运维人员操控和测量整个网络。数据平面主要负责截获不同服务之间的调用请求并对其进行处理。

▲图1-1 服务网格典型架构
与微服务架构相比，服务网格具有3个方面的优势。可观测性：所有服务间通信都需要经过服务网格，所以在此处可以捕获所有调用相关的指标数据，如来源、目的地、协议、URL、状态码等，并通过API供运维人员观测。流量控制：服务网格可以为服务提供智能路由、超时重试、熔断、故障注入和流量镜像等控制能力。安全性：服务网格提供认证服务、加密服务间通信以及强制执行安全策略的能力。
4. DevOps
DevOps（Development & Operations，开发和运维）是软件开发人员和IT人员之间的合作过程，是一种工作环境、文化和实践的集合，目标是高效地自动执行软件交付和基础架构更改流程。开发和运维人员通过持续不断的沟通和协作，可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。
开发人员通常以持续集成和持续交付（CI/CD）的方式，快速交付高质量的应用程序。持续集成是指开发人员频繁地将开发分支代码合并到主干分支，这些开发分支在真正合并到主干分支之前，都需要持续编译、构建和测试，以提前检查和验证其存在的缺陷。持续集成的本质是确保开发人员新增的代码与主干分支正确集成。
持续交付是指软件产品可以稳定、持续地保持随时可发布的状态，它的目标是促进产品迭代更频繁，持续为用户创造价值。与持续集成关注代码构建和集成相比，持续交付关注的是可交付的产物。
持续集成只是对新代码与原有代码的集成做了检查和测试，在可交付的产物真正交付至生产环境之前，我们一般还需要将其部署至测试环境和预发布环境，进行充分的集成测试和验证，最后才会交付至生产环境，保证新增代码在生产环境中稳定可用。
使用持续集成和持续交付的优势如下。避免重复性劳动，减少人工操作的错误：自动化部署可以将开发运维人员从应用程序集成、测试和部署等重复性劳动环节中解放出来，而且人工操作容易犯错，机器犯错的概率则非常小。提前发现问题和缺陷：持续集成和持续交付能让开发和运维人员更早地获取应用程序的变更情况，更早地进入测试和验证阶段，也就能更早地发现和解决问题。更频繁的迭代：持续集成和持续交付缩短了从开发、集成、测试、部署到交付各个环节的时间，中间有任何问题都可以快速“回炉”改造和更新，整个过程敏捷且可持续，大大提高了应用程序的迭代频率和效率。更高的产品质量：持续集成可以结合代码预览、代码质量检查等功能，对不规范的代码进行标识和通知；持续交付可以在产品上线前充分验证应用可能存在的缺陷，最终提供给用户一款高质量的产品。