集群服务器

这篇文章也算是对于课程 《 PHP秒杀系统 高并发高性能的极致挑战 》 的一个整理，视频之外的另外一种形式吧。 大家也许开发过高并发的系统或者秒杀程序，但肯定都有接触过，像电商平台的秒杀、抢购等活动，还有12306春运抢票。 互联网公司，做一些有奖活动，而且数量有限，奖品给力，如果是先到先得的策略，那就类似秒杀系统了。 这类系统最大的问题就是活动周期短，瞬间流量大（高并发），很少人可以成功下单，绝大多数人都是很遗憾。所以从运营体验上，没有成功下单的人，心里肯定是不好受的，如果这时候，因为技术、网络问题，影响用户体验，那就更是骂声一片。 这里，就来讲一讲技术在这种情况下，会发生和要做的事。 下面是基本的概念的建立。 第一：高并发 技术要做的事，一方面优化程序，让程序性能最优，单次请求时间能从50ms优化到25ms，那就可以在一秒钟内成功响应翻倍的请求了。 另一方面就是增加服务器，用更大的集群来处理用户请求，设计好一个可靠且灵活扩充的分布式方案就更加重要了。 第二：时间短 火热的秒杀活动，真的是一秒钟以内就会把商品抢购一空，而大部分用户的感受是，提交订单的过程却要等待好几秒、甚至十几秒，更糟糕的当然是请求报错。 那么一个好的秒杀体验，当然希望尽可能减少用户等待时间，准确的提示用户当前是否还有商品库存。而这些，也是需要有优秀的程序设计来保证的。 第三：系统容量预估 系统设计的时候

宜信公司从2018年初开始建设容器云，至今，容器云的常用基本功能已经趋于完善，主要包括服务管理、应用商店、Nginx配置、存储管理、CI/CD、权限管理等，支持100+业务线、3500+的容器运行。伴随公司去VMware以及DevOps、微服务不断推进的背景，后续还会有更多的业务迁移到容器云上，容器云在宜信发挥着越来越重要的作用。本次分享主要介绍宜信容器云平台的背景、主要功能、落地实践及未来规划。 一、宜信容器云平台背景 宜信容器云平台的建设背景主要包括： 提高资源利用率。容器云建设之前，每台物理机上平均运行的虚拟机大概是20个，使用了容器云之后，每台物理机上平均运行的容器数达到50个；之前的CPU利用率大概在10%左右，迁移到容器云后，CPU利用率提高到20%以上，整个资源利用率得到了极大的提升。 提升服务可靠性。传统的虚拟机运维方式下，当机器宕机或系统故障时，需要运维手动重启虚拟机和服务，整个过程最快需要几十分钟到几个小时才能解决；使用容器云后，通过健康检查的方式，一旦发现有问题就自动重启恢复服务，可以达到分钟级甚至秒级的恢复。 节约成本。通过容器云提高了资源利用率，同时也节约了成本。公司每年会采购一些商业化软件，如虚拟化软件、商业存储等，费用动辄千万。我们基于开源技术自研一套容器解决方案，每年为公司节省上千万的软件采购和维保费用。 弹性伸缩。我们公司每年都会组织财富峰会

1.ZooKeeper安装和启动 1.下载解压ZooKeeper ZooKeeper官方地址： http://zookeeper.apache.org/ 下载当前稳定版本：zookeeper-3.4.6.tar.gz 解压如下： [lizhiwei@localhost ZooKeeper]$ tar -zxvf zookeeper-3.4.6......[lizhiwei@localhost ZooKeeper]$ lltotal 17292drwxr-xr-x. 10 lizhiwei lizhiwei 4096 Feb 20 2014 zookeeper-3.4.6-rwxrwxr-x. 1 lizhiwei lizhiwei 17699306 Sep 13 23:25 zookeeper-3.4.6.tar.gz[lizhiwei@localhost ZooKeeper]$ cd zookeeper-3.4.6[lizhiwei@localhost zookeeper-3.4.6]$ lltotal 1552drwxr-xr-x. 2 lizhiwei lizhiwei 4096 Oct 19 00:56 bin-rw-rw-r--. 1 lizhiwei lizhiwei 82446 Feb 20 2014 build.xml-rw-rw-r--. 1 lizhiwei

在2018年年初，Jenkins X首次发布，它由Apache Groovy语言的创建者Jame Strachan创建。Jenkins X 是一个高度集成化的 CI/CD 平台，基于 Jenkins 和 Kubernetes 实现，旨在解决微服务体系架构下的云原生应用的持续交付的问题，简化整个云原生应用的开发、运行和部署过程。仅需一条Jenkins X命令，管理员可以创建一个Kubernetes集群，并安装用于管理应用程序、创建流水线并部署一个应用程序到不同的环境中的工具。 Jenkin X还是由插件配置的可扩展自动化服务器，可充当持续集成（CI）服务器，持续部署（CD）hub和自动化测试。 Jenkins X（也称为JX）可以轻松地安装在现有的云提供商上（如GKE、AKS等）。或者，如果你由本地Kubernetes集群，也可以使用Jenkins X。通过jx命令，你可以在本地或远程云提供商（如Google Cloud Platform）上快速部署集群。 本文将教您完成在Ubuntu Server 18.04上运行的现有Kubernetes集群上安装Jenkins X的过程。 前期准备 我将演示在本地和Google Cloud Platform上部署Kubernetes集群（使用Jenkins X）。为此，您需要： 已安装Kubernetes的Ubuntu Server的运行实例。

1. Linux系统配置 1.1. vm.overcommit_memory设置 overcommit_memory文件指定了内核针对内存分配的策略，其值可以是0、1、2。 0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。 1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。 2， 表示内核允许分配超过所有物理内存和交换空间总和的内存 jenkins_service@jenkinsservice:~/redis-3.0.1$ sudo sysctl vm.overcommit_memory=1 vm.overcommit_memory = 1 1.2. Transparent Huge Pages开启 THP（Transparent Huge Pages）是一个使管理Huge Pages自动化的抽象层。 目前需要注意的是，由于实现方式问题，THP会造成内存锁影响性能，尤其是在程序不是专门为大内内存页开发的时候，简单介绍如下： 操作系统后台有一个叫做khugepaged的进程，它会一直扫描所有进程占用的内存，在可能的情况下会把4kpage交换为Huge Pages，在这个过程中，对于操作的内存的各种分配活动都需要各种内存锁，直接影响程序的内存访问性能，并且，这个过程对于应用是透明的

1. YARN产生背景 MapReduce本身存在着一些问题： 1）JobTracker单点故障问题；如果Hadoop集群的JobTracker挂掉，则整个分布式集群都不能使用了。 2）JobTracker承受的访问压力大，影响系统的扩展性。 3）不支持MapReduce之外的计算框架，比如Storm、Spark、Flink等。 与旧MapReduce相比，YARN采用了一种分层的集群框架，具有以下几种优势。 1）Hadoop2.0提出了HDFSFederation；它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展。对于运行中NameNode的单点故障，通过 NameNode热备方案（NameNode HA）实现 。 2） YARN通过将资源管理和应用程序管理两部分剥离开来，分别由ResourceManager和ApplicationMaster进程来实现。其中，ResouceManager专管资源管理和调度，而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等。 3）YARN具有向后兼容性，用户在MR1上运行的作业，无需任何修改即可运行在YARN之上。 4）对于资源的表示以内存为单位（在目前版本的 Yarn 中没有考虑 CPU的占用），比之前以剩余 slot 数目为单位更合理。 5）支持多个框架，YARN不再是一个单纯的计算框架

单机模式配置： Zookeeper 的启动脚本在 bin 目录下，Linux 下的启动脚本是 zkServer.sh 在你执行启动脚本之前，还有几个基本的配置项需要配置一 下，Zookeeper 的配置文件在 conf 目录下，这个目录下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg，因为 Zookeeper 在启动时会找这个文件作为默认配置文件。 tickTime=2000 dataDir=D:/devtools/zookeeper-3.2.2/build clientPort=2181 tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。 dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。 clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。 当这些配置项配置好后，你现在就可以启动 Zookeeper 了，启动后要检查 Zookeeper 是否已经在服务，可以通过 netstat – ano

1.Dubbo是什么？ Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。 RPC 指的是远程调用协议，也就是说两个服务器交互数据。 2.Dubbo的由来？ 互联网的快速发展，Web应用程序的规模不断扩大，一般会经历如下四个发展阶段。 单一应用架构 当网站流量很小时，只需一个应用， 将所有功能都部署在一起即可 。 垂直应用架构 当访问量逐渐增大，单一应用按照有业务线 拆成多个应用 ，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免， 将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心 ，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现， 此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 3.Dubbo的主要应用场景？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在 某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析 zookeeper的工作原理，对于如何使用zookeeper不是本文讨论的重点。 1 Zookeeper的基本概念 1.1 角色 Zookeeper中的角色主要有以下三类，如下表所示： 系统模型如图所示： 1.2 设计目的 1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。 2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。 3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 4 .等待无关（wait-free）

前言 Kubernetes的教程一直在编写，目前已经初步完成了以下内容： 1）基础理论 2）使用Minikube部署本地Kubernetes集群 3）使用Kubeadm创建集群 接下来还会逐步完善本教程，比如Helm、ELK、Windows Server容器等等。 目录 Kubernetes主体架构 1.1.主要核心组件 1.1.1. Master组件 1.1.2. 节点（Node）组件 1.1.3. 插件 1.2. 基本概念 1.2.1. 容器组（Pod） 1.2.2. 服务（Service） 1.2.3. 卷（Volume） 1.2.4. 标签（Labels）和标签选择器（Label Selector） 1.2.5. 复制控制器（Replication Controller，RC） 1.2.6. 副本集控制器（Replica Set，RS） 1.2.7. 部署控制器(Deployment) 1.2.8. StatefulSet 1.2.9. 后台支撑服务集（DaemonSet） 1.2.10. 一次性任务（Job） Kubernetes主体架构 k8s的整体架构如下图所示： C:\Users\Lys_Desktop\Documents\Tencent Files\512982554\FileRecv\思维导图1.png 1.1主要核心组件 1.1.1Master组件