提问

#楼主# 2019-11-14

跳转到指定楼层
本帖最后由 光小云 于 2019-11-14 15:21 编辑

最近,关于“微服务即将过时”的说法甚嚣尘上,这到底是不是真相呢,这篇文章我们就来了解一下。
传统的微服务
用传统的方式构建一个复杂的、可扩展和有弹性的微服务架构是非常具有挑战性的。我们需要处理服务之间的交互,服务发现、监控、容错性、日志收集和服务熔断等等,服务数量日益增多而且每个服务都需要有这些共同的功能。
在微服务架构中,大多数情况下我们依靠一些开源软件处理服务之间的通信,以及实现负载平衡、断路器、性能指标、分布式追踪等功能。像Netflix 这样的公司开源了他们自己的库,比如断路器 Hystrix、服务发现 Eureka、负载均衡Ribbon,这些开源软件很受企业的欢迎并且得到了广泛应用。
1.png

但是,这些组件需要在应用代码中配置,并且针对不同的开发语言有不同的实现。每当你升级了这些外部组件,都需要更新应用代码,验证并部署更新。这就带来了一个问题,这些配置侵入你的业务代码,和你的业务代码耦合在了一起。毫无疑问,这种紧密耦合会增加应用的复杂度,因为开发人员现在还需要关注如何配置这些组件,以便在出问题时能排查故障。
服务网格
服务网格(Service Mesh)的出现拯救了我们。它将这种复杂性和你的应用程序分离,通过一个服务代理为你的应用提供一系列功能,如服务发现、监控、流量控制、日志记录、服务限流和服务熔断等等。而你的应用只需要关注业务功能实现,并且应用感知不到代理的存在。
Istio
Istio 是 Service Mesh 的最佳开源实现之一,由 Google 和 IBM 维护。它让你无需深入了解底层基础架构即可部署微服务。
下面这个漫画很好的描述了什么是 Istio:
2.jpg
Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio,只需要在您的环境中部署一个特殊的 sidecar 代理,使用 Istio 控制平面功能配置和管理代理,拦截微服务之间的所有网络通信:
  • HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
  • 通过丰富的路由规则、重试、故障转移和故障注入,可以对流量行为进行细粒度控制。
  • 可插入的策略层和配置 API,支持访问控制、速率限制和配额。
  • 对出入集群入口和出口中所有流量的自动度量指标、日志记录和追踪。
  • 通过强大的基于身份的验证和授权,在集群中实现安全的服务间通信。

Istio 旨在实现可扩展性,满足各种部署需求。

Sidecar 边车模式
在Azure Architecture Center的云设计模式中是这么介绍边车模式的:
Deploy components of an application into a separate process or container to provide isolation and encapsulation.
---Sidecar pattern
3.jpg

边车模式是一种分布式架构的设计模式。如上图所示,边车就是加装在摩托车旁来达到拓展功能的目的,比如行驶更加稳定,可以拉更多的人和货物,坐在边车上的人可以给驾驶员指路等。边车模式通过给应用服务加装一个“边车”来达到控制和逻辑的分离的目的。
Istio 架构
  • Istio 是独立于平台的,可以部署在 Kubernetes、Consul和虚拟机上。

Istio 的组成
  • Envoy:智能代理、流量控制
  • Pilot:服务发现、流量管理
  • Mixer:访问控制、遥测
  • Citadel:终端用户认证、流量加密
  • Galley:验证、处理和分发配置

Service mesh 关注的方面
  • 可观察性
  • 安全性
  • 可运维性
  • 可拓展性

  • Istio 的策略执行组件可以扩展和定制,同时也是可拔插的
  • Istio 在数据平面为每个服务中注入一个 Envoy 代理以 Sidecar 形式运行来劫持所有进出服务的流量,同时对流量加以控制,通俗的讲就是应用程序你只管处理你的业务逻辑,其他的事情 Sidecar 会汇报给 Istio 控制平面处理
  • 应用程序只需关注于业务逻辑(这才能生钱)即可,非功能性需求交给 Istio


DevOps
DevOps 是 Development 和 Operations的组合,是一种重视软件开发人员(Dev)和运维技术人员(Ops)之间沟通合作的文化。DevOps
并不是指某种或某些工具的集合,而是一种方法论,我们可以用不同的工具软件来实现打破开发和运维的壁垒。
4.jpg
通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说,就是在软件交付和部署过程中提高沟通与协作的效率,旨在更快、更可靠的的发布更高质量的产品。
由此可见,DevOps 的第一步就是做好 CI/CD。
什么是 CI/CD
5.jpg
持续集成(Continuous Integration),简称 CI。在开发过程中,源代码变更后触发拉取、构建和单元测试(在大多数情况下)的过程,持续集成可根据实际情况定制流水线任务,最终目的都是为了形成一个可交付版本。
持续交付(Continuous Delivery)或持续部署(Continuous Deployment),简称 CD。持续交付意味着所有的变更都可以被部署到生产环境中,但是一般情况下生产部署为手动触发,其他例如测试环境、准生产环境则可以自动触发持续部署流水线。
为什么需要 CI/CD
"在我本地运行没问题"
在没有 CI/CD 的传统开发模式下,我们可能遇到过类似这样的尴尬场景:
小明修复完一个 Bug 后准备提交测试,正好小强也修复完一个 Bug,于是小明拉取最新代码打包,通知了运维的同事部署到测试环境,一顿操作后运维通知测试的同事部署完毕,测试结果表示 Bug 依旧存在,小强表示这锅我不背,小明大呼:"在我本地运行没问题",一番忙活后小明发现是自己忘记提交了一个文件。
当然,这种传统开发模式实际遇到的问题可能更加复杂,来看看出现了哪些问题:
  • 没有单元测试
  • 手动构建应用程序包(镜像)。
  • 手动部署
  • 多余的沟通成本

首先,持续集成并不能保证找出所有集成时出现的 bug。持续集成的排错能力取决于测试技术,众所周知,测试无法证明已经找出了所有的错误。关键是在于:持续集成可以及时找出 bug,这就已经值回它的开销了。
那么假如有 CI/CD ,情况会是怎样的?
小明修复了一个 Bug 后,编写单元测试,测试无误后提交了代码,push 到代码仓库,代码仓库通过 webhook 通知 CI 服务器启动流水线任务,流水线首先拉取这次 commit 的代码,执行单元测试,失败(因为缺少的文件),CI 向这次 commit 的作者发出通知(邮件或者其他形式),由于单元测试的存在,小明很快找到问题了原因。重新提交后单元测试通过,流水线自动完成构建,将程序包(镜像)推送到测试服务器(镜像仓库)。最后通知测试环境自动完成部署。
当然,即便没有单元测试,CI/CD 也能让我们节约很多人员沟通、手动构建、手动部署的时间。这就是 CI/CD 的作用,也正是 DevOps 的目的。
集成越频繁,效果越好
持续集成最基本的好处就是:它避免了我们开会找bug —— 因为某个人踏进了别人的领域,影响了别人的代码,而被影响的人还不知道发生了什么 bug 就出现了。这种 bug很难找出来,因为问题不是出在某一个人的领域里,而是出在两个人的沟通上。随着时间的推移,问题会逐渐恶化。通常,在集成阶段出现的bug早在几周甚至几个月之前就已经存在了。结果是集成时要花大量的时间和精力去寻找这些 bug。
如果你只是偶尔集成一次,比如几天才集成一次,那么每次集成都要花大量时间和精力找 bug,你会非常痛苦,没错,很尴尬,你要做的最后一件事就是 —— 更频繁地集成!
如何选择 CI/CD 工具
Jenkins 作为功能完备的老牌 CI/CD 工具,经过多年积累,拥有丰富的插件和社区资源,但是如果你的团队没有相关专家,你们可能会面对:
  • 配置复杂(许多运维老手都这么觉得)
  • 运维难度高,例如流水线残留的文件会让磁盘迅速爆满
  • 新手难以快速掌握

所以小团队应该选择更加轻量级灵活的工具,Gitlab CI 似乎改善了一些 Jenkins 遇到的问题,但是它只支持 Gitlab,既然我们想尝鲜,在 Docker 大行其道的今天,何不尝试一下Drone?
为什么选择 Drone
Drone 完全构建于容器技术之上,使用简单的YAML配置文件(docker-compose的超集)来定义和执行Docker容器中的Pipelines。
所以,它的一切构建都发生在容器里,构建结束后不会有多余的残留,而且和 Jenkins 比起来,YAML 配置语法简洁而美观,Drone 也拥有丰富易用的插件,而且非常容易上手。同时它也能很轻松地在 Kubernetes 里安装。
6.png
总结
7.png

Istio 可以部署在 Kubernetes 或者 Consul 中,推荐采用 Kubernetes,它能够提供应用程序生命周期的管理,例如部署、扩容、自动恢复等等,同时它的可扩展性也允许自定义扩展其功能。
那么一个高可用的Kubernetes集群是必不可少的,然后将其余的一切交给它管理就是一个水到渠成的过程。部署和管理微服务的生命周期,让微服务具备自动伸缩、可扩展和高弹性的能力。像上图中的一些公共服务,则可以独立于Kubernetes 之外部署,当然也可以根据实际情况调整。最后配置好自动化流水线,就可以展现 DevOps 的威力了。
显然,Service Mesh,CI/CD 和 Kubernetes 是为了解决我们之前遇到的许多问题,而引入新的技术必然带来一些考验,即使你现在不想采用这些技术,也要将其作为首要任务,我们都知道克服技术差距有多困难。
作者:光环云 张劲航。 转载请注明作者及出处。

550二维码进群.png

转播转播
回复

使用道具

联系楼主
*
*
客户公司所在区域:
*
产品:
*
简述客户的业务场景和需求
*
*
*

成为第一个回答人

B Color Link Quote Code Smilies
光环云社区 |京ICP备18044167号-13|

京公网安备 11010102003758号