云架构师进阶攻略(3)-从容器到配置中心、日志中心、监控中心

九、基于Mesos和Kubernetes了解容器平台

搭建完毕虚拟化层和云平台层,接下来就是容器层了。

Docker有几个核心技术,一个是镜像,一个是运行时,运行时又分看起来隔离的namespace和用起来隔离的cgroup。

Docker的镜像也是一种Copy on Write的镜像格式,下面的层级是只读的,所有的写入都在最上层。

对于运行时,Docker使用的namespace除了network namespace外,还有很多,如下表格所示。

Docker对于cgroup的使用是在运行Docker的时候,在路径/sys/fs/cgroup/cpu/docker/下面控制容器运行使用的资源。

可见容器并没有使用更新的技术,而是一种新型的交付方式,也即应用的交付应该是一容器镜像的方式交付,容器一旦启动起来,就不应该进入容器做各种修改,这就是不可改变基础设施。

由于容器的镜像不包含操作系统内核,因而小的多,可以进行跨环境的迁移和弹性伸缩。

我写下了下面的文章,总结了几点容器的正确使用姿势。

容器化的本质?基于镜像的跨环境迁移

有关容器的六大误区和八大正确场景

有了容器之后,接下来就是容器平台的选型,其实swarm, mesos, kubernetes各有优势,也可以在不同的阶段,选择使用不同的容器平台。

Docker, Kubernetes, DCOS 不谈信仰谈技术

容器平台选型的十大模式:Docker、DC/OS、K8S谁与当先?

基于Mesos的DCOS更像是一个数据中心管理平台,而非仅仅容器管理平台,他可以兼容Kubernetes的编排,同时也能跑各种大数据应用。

DC/OS的基本思想——为什么说他是数据中心操作系统

号称了解mesos双层调度的你,先来回答下面这五个问题!

DC/OS的容器功能

DC/OS的网络功能

DC/OS的存储功能

DC/OS的服务发现与负载均衡功能

在容器领域,基于Kubernetes的容器编排已经成为事实标准。

基于万节点Kubernetes支撑大规模云应用实践

支撑大规模公有云的Kubernetes改进与优化 (1)

支撑大规模公有云的Kubernetes改进与优化 (2)

支撑大规模公有云的Kubernetes改进与优化 (3)

为支撑高并发应用的 Kubernetes 的性能优化

当我们深入分析Kubernetes管理容器模式的时候,我们也能看到熟悉的面孔。

在Kubernetes里面,租户之间靠namespace进行隔离,这个不是Docker的namespace,而是Kubernetes的概念。

API Server的鉴权,也是基于Role Based Access Control模式。

Kubernetes对于namespace,也有Quota配置,使用ResourceQuota。

当Kubernetes想选择一个节点运行pod的时候,选择的过程也是通过预选和优选两个阶段。

  • 预选(Filtering)
    • PodFitsResources满足资源
    • PodSelectorMatches符合标签
    • PodFitsHost符合节点名称
  • 优选(Weighting)
    • LeastRequestedPriority资源消耗最小
    • BalancedResourceAllocation资源使用最均衡

Kubernetes规定了以下的网络模型定义。

  • 所有的容器都可以在不使用NAT的情况下同别的容器通信
  • 所有的节点都可以在不使用NAT的情况下同所有的容器通信
  • 容器的地址和别人看到的地址一样

也即容器平台应该有自己的私有子网,常用的有Flannel, Calico, Openvswitch都是可以的。

既可以使用Overlay的方式,如图flannel.

也可以使用BGP的方式,如图Calico

十、基于Hadoop和Spark了解大数据平台

对于数据架构的部分,其实经历了三个过程,分别是Hadoop Map-Reduce 1.0,基于Yarn的Map-Reduce 2.0, 还有Spark。

如下图是Map-Reduce 1.0的过程。

Map-Reduce的过程将一个大任务,split称为多个Map Task,分散到多台机器并行处理,将处理的结果保存到本地,第二个阶段,Reduce Task将中间结果拷贝过来,将结果集中处理,取得最终结果。

在Map-Reduce 1.0的时候,跑任务的方式只有这一种,为了应对复杂的场景,将任务的调度和资源的调度分成两层。其中资源的调用由Yarn进行,Yarn不管是Map还是Reduce,只要向他请求,他就找到空闲的资源分配给他。

每个任务启动的时候,专门启动一个Application Master,管理任务的调度,他是知道Map和Reduce的。这就是Map-Reduce 2.0如下图。

这里Yarn相当于外包公司的老板,所有的员工都是worker,都是他的资源,外包公司的老板是不清楚接的每一个项目的。

Application Master相当于接的每个项目的项目经理,他是知道项目的具体情况的,他在执行项目的时候,如果需要员工干活,需要向外包公司老板申请。

Yarn是个通用的调度平台,能够跑Map-Reduce 2,就能跑Spark。

Spark也是创建Spark自己的Application Master,用于调度任务。

Spark之所以比较快,是因为前期规划做的好,不是像Map-Reduce一样,每一次分配任务和聚合任务都要写一次硬盘,而是将任务分成多个阶段,将所有在一个Map都做了的合成一个阶段,这样中间不用落盘,但是到了需要合并的地方,还是需要落盘的。

对于Hadoop和Spark的基本原理,我写了下面的文章。

通俗说基于Yarn的Map-Reduce过程

通俗说Spark

真正写Map-Reduce程序的时候,有很多的方法论,这里我总结了几个,供您参考。

大数据方法论之优化Map-Reduce过程

大数据方法论之网页消重的Map-Reduce算法

大数据方法论之PageRank的Map-Reduce计算

大数据方法论之Nutch基于Map-Reduce的爬取方法

十一、基于Lucene和ElasticSearch了解搜索引擎

当大数据将收集好的数据处理完毕之后,一般会保存在两个地方,一个是正向索引,可以用Hbase,Cassandra等文档存储,一个是反向索引,方便搜索,就会保存在基于Lucene的ElasticSearch里面。

对于Lucene,在职业生涯的早期,写过一个《Lucene 原理与代码分析完整版》有500多页。

对于搜索引擎的通用原理,写了下面的文章。

不是技术也能看懂搜索引擎

搜索引擎的设计(1):词典的设计

搜索引擎的设计(2):倒排表的设计上

搜索引擎的设计(3):倒排表的设计下

十二、基于SpringCloud了解微服务

最后到了应用架构,也即微服务。

接下来细说微服务架构设计中不得不知的十大要点。

设计要点一:负载均衡 + API 网关

在实施微服务的过程中,不免要面临服务的聚合与拆分。

当后端服务的拆分相对比较频繁的时候,作为手机 App 来讲,往往需要一个统一的入口,将不同的请求路由到不同的服务,无论后面如何拆分与聚合,对于手机端来讲都是透明的。

有了 API 网关以后,简单的数据聚合可以在网关层完成,这样就不用在手机 App 端完成,从而手机 App 耗电量较小,用户体验较好。

有了统一的 API 网关,还可以进行统一的认证和鉴权,尽管服务之间的相互调用比较复杂,接口也会比较多。

API 网关往往只暴露必须的对外接口,并且对接口进行统一的认证和鉴权,使得内部的服务相互访问的时候,不用再进行认证和鉴权,效率会比较高。

有了统一的 API 网关,可以在这一层设定一定的策略,进行 A/B 测试,蓝绿发布,预发环境导流等等。

API 网关往往是无状态的,可以横向扩展,从而不会成为性能瓶颈。

设计要点二:无状态化与独立有状态集群

影响应用迁移和横向扩展的重要因素就是应用的状态。无状态服务,是要把这个状态往外移,将 Session 数据,文件数据,结构化数据保存在后端统一的存储中,从而应用仅仅包含商务逻辑。

状态是不可避免的,例如 ZooKeeper,DB,Cache 等,把这些所有有状态的东西收敛在一个非常集中的集群里面。

整个业务就分两部分,一个是无状态的部分,一个是有状态的部分。

无状态的部分能实现两点:

  • 跨机房随意地部署,也即迁移性。
  • 弹性伸缩,很容易地进行扩容。

有状态的部分,如 ZooKeeper,DB,Cache 有自己的高可用机制,要利用到它们自己高可用的机制来实现这个状态的集群。

虽说无状态化,但是当前处理的数据,还是会在内存里面的,当前的进程挂掉数据,肯定也是有一部分丢失的。

为了实现这一点,服务要有重试的机制,接口要有幂等的机制,通过服务发现机制,重新调用一次后端服务的另一个实例就可以了。

设计要点三:数据库的横向扩展

数据库是保存状态,是最重要的也是最容易出现瓶颈的。有了分布式数据库可以使数据库的性能随着节点增加线性地增加。

分布式数据库最最下面是 RDS,是主备的,通过 MySQL 的内核开发能力,我们能够实现主备切换数据零丢失。

所以数据落在这个 RDS 里面,是非常放心的,哪怕是挂了一个节点,切换完了以后,你的数据也是不会丢的。

再往上就是横向怎么承载大的吞吐量的问题,上面有一个负载均衡 NLB,用 LVS,HAProxy,Keepalived,下面接了一层 Query Server。

Query Server 是可以根据监控数据进行横向扩展的,如果出现了故障,可以随时进行替换的修复,对于业务层是没有任何感知的。

另外一个就是双机房的部署,DDB 开发了一个数据运河 NDC 的组件,可以使得不同的 DDB 之间在不同的机房里面进行同步。

这时候不但在一个数据中心里面是分布式的,在多个数据中心里面也会有一个类似双活的一个备份,高可用性有非常好的保证。

设计要点四:缓存

在高并发场景下缓存是非常重要的。要有层次的缓存,使得数据尽量靠近用户。数据越靠近用户能承载的并发量也越大,响应时间越短。

在手机客户端 App 上就应该有一层缓存,不是所有的数据都每时每刻从后端拿,而是只拿重要的,关键的,时常变化的数据。

尤其对于静态数据,可以过一段时间去取一次,而且也没必要到数据中心去取,可以通过 CDN,将数据缓存在距离客户端最近的节点上,进行就近下载。

有时候 CDN 里面没有,还是要回到数据中心去下载,称为回源,在数据中心的最外层,我们称为接入层,可以设置一层缓存,将大部分的请求拦截,从而不会对后台的数据库造成压力。

如果是动态数据,还是需要访问应用,通过应用中的商务逻辑生成,或者去数据库读取,为了减轻数据库的压力,应用可以使用本地的缓存,也可以使用分布式缓存。

如 Memcached 或者 Redis,使得大部分请求读取缓存即可,不必访问数据库。

当然动态数据还可以做一定的静态化,也即降级成静态数据,从而减少后端的压力。

设计要点五:服务拆分与服务发现

当系统扛不住,应用变化快的时候,往往要考虑将比较大的服务拆分为一系列小的服务。

这样第一个好处就是开发比较独立,当非常多的人在维护同一个代码仓库的时候,往往对代码的修改就会相互影响。

常常会出现我没改什么测试就不通过了,而且代码提交的时候,经常会出现冲突,需要进行代码合并,大大降低了开发的效率。

另一个好处就是上线独立,物流模块对接了一家新的快递公司,需要连同下单一起上线,这是非常不合理的行为。

我没改还要我重启,我没改还让我发布,我没改还要我开会,都是应该拆分的时机。

再就是高并发时段的扩容,往往只有最关键的下单和支付流程是核心,只要将关键的交易链路进行扩容即可,如果这时候附带很多其他的服务,扩容既是不经济的,也是很有风险的。

另外的容灾和降级,在大促的时候,可能需要牺牲一部分的边角功能,但是如果所有的代码耦合在一起,很难将边角的部分功能进行降级。

当然拆分完毕以后,应用之间的关系就更加复杂了,因而需要服务发现的机制,来管理应用相互的关系,实现自动的修复,自动的关联,自动的负载均衡,自动的容错切换。

设计要点六:服务编排与弹性伸缩

当服务拆分了,进程就会非常的多,因而需要服务编排来管理服务之间的依赖关系,以及将服务的部署代码化,也就是我们常说的基础设施即代码。

这样对于服务的发布,更新,回滚,扩容,缩容,都可以通过修改编排文件来实现,从而增加了可追溯性,易管理性,和自动化的能力。

既然编排文件也可以用代码仓库进行管理,就可以实现一百个服务中,更新其中五个服务,只要修改编排文件中的五个服务的配置就可以。

当编排文件提交的时候,代码仓库自动触发自动部署升级脚本,从而更新线上的环境。

当发现新的环境有问题时,当然希望将这五个服务原子性地回滚,如果没有编排文件,需要人工记录这次升级了哪五个服务。

有了编排文件,只要在代码仓库里面 Revert,就回滚到上一个版本了。所有的操作在代码仓库里都是可以看到的。

设计要点七:统一配置中心

服务拆分以后,服务的数量非常多,如果所有的配置都以配置文件的方式放在应用本地的话,非常难以管理。

可以想象当有几百上千个进程中有一个配置出现了问题,是很难将它找出来的,因而需要有统一的配置中心,来管理所有的配置,进行统一的配置下发。

在微服务中,配置往往分为以下几类:

  • 一类是几乎不变的配置,这种配置可以直接打在容器镜像里面。
  • 第二类是启动时就会确定的配置,这种配置往往通过环境变量,在容器启动的时候传进去。
  • 第三类就是统一的配置,需要通过配置中心进行下发。例如在大促的情况下,有些功能需要降级,哪些功能可以降级,哪些功能不能降级,都可以在配置文件中统一配置。

设计要点八:统一日志中心

同样是进程数目非常多的时候,很难对成千上百个容器,一个一个登录进去查看日志,所以需要统一的日志中心来收集日志。

为了使收集到的日志容易分析,对于日志的规范,需要有一定的要求,当所有的服务都遵守统一的日志规范的时候,在日志中心就可以对一个交易流程进行统一的追溯。

例如在最后的日志搜索引擎中,搜索交易号,就能够看到在哪个过程出现了错误或者异常。

设计要点九:熔断,限流,降级

服务要有熔断,限流,降级的能力,当一个服务调用另一个服务,出现超时的时候,应及时返回,而非阻塞在那个地方,从而影响其他用户的交易,可以返回默认的托底数据。

当一个服务发现被调用的服务,因为过于繁忙,线程池满,连接池满,或者总是出错,则应该及时熔断,防止因为下一个服务的错误或繁忙,导致本服务的不正常,从而逐渐往前传导,导致整个应用的雪崩。

当发现整个系统的确负载过高的时候,可以选择降级某些功能或某些调用,保证最重要的交易流程的通过,以及最重要的资源全部用于保证最核心的流程。

还有一种手段就是限流,当既设置了熔断策略,又设置了降级策略,通过全链路的压力测试,应该能够知道整个系统的支撑能力。

因而就需要制定限流策略,保证系统在测试过的支撑能力范围内进行服务,超出支撑能力范围的,可拒绝服务。

当你下单的时候,系统弹出对话框说 “系统忙,请重试”,并不代表系统挂了,而是说明系统是正常工作的,只不过限流策略起到了作用。

设计要点十:全方位的监控

当系统非常复杂的时候,要有统一的监控,主要有两个方面,一个是是否健康,一个是性能瓶颈在哪里。

当系统出现异常的时候,监控系统可以配合告警系统,及时地发现,通知,干预,从而保障系统的顺利运行。

当压力测试的时候,往往会遭遇瓶颈,也需要有全方位的监控来找出瓶颈点,同时能够保留现场,从而可以追溯和分析,进行全方位的优化。

我会将微服务相关的文章更加细化的写出来。

微服务化之服务拆分与服务发现

微服务化之缓存的设计

微服务化之无状态化与容器化

微服务化的数据库设计与读写分离

微服务的接入层设计与动静资源隔离

微服务化的基石——持续集成

有关微服务和容器之间的结合,写了下面的文章。

为什么 kubernetes 天然适合微服务

微服务化不同阶段 Kubernetes 的不同玩法

金融创新业务基于容器云的微服务化实践

深入解读Service Mesh背后的技术细节

深入解读Service Mesh的数据面Envoy

原文发布于微信公众号 - 物流IT圈(exiter18)

原文发表时间:2019-01-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券