数据专栏

智能大数据搬运工,你想要的我们都有

科技资讯

科技学院

科技百科

科技书籍

网站大全

软件大全

部署生产级的 Kubernetes 集群,使用kubespray 项目源码, https://github.com/openthings/kubespray 国内部署, https://github.com/zhangguanzhang/Kubernetes-ansible 欢迎加入 kubernetes slack , channel #kubespray . 获得邀请从这里 here 可以部署到 AWS, GCE, Azure, OpenStack, vSphere, Oracle Cloud Infrastructure (Experimental), 或 Baremetal Highly available cluster Composable (Choice of the network plugin for instance) Supports most popular Linux distributions Continuous integration tests 快速开始 To deploy the cluster you can use : Ansible # Install dependencies from ``requirements.txt`` sudo pip install -r requirements.txt # Copy ``inventory/sample`` as ``inventory/mycluster`` cp -rfp inventory/sample/* inventory/mycluster # Update Ansible inventory file with inventory builder declare -a IPS=(10.10.1.3 10.10.1.4 10.10.1.5) CONFIG_FILE=inventory/mycluster/hosts.ini python3 contrib/inventory_builder/inventory.py ${IPS[@]} # Review and change parameters under ``inventory/mycluster/group_vars`` cat inventory/mycluster/group_vars/all.yml cat inventory/mycluster/group_vars/k8s-cluster.yml # Deploy Kubespray with Ansible Playbook ansible-playbook -i inventory/mycluster/hosts.ini cluster.yml Note: When Ansible is already installed via system packages on the control machine, other python packages installed via sudo pip install -r requirements.txt will go to a different directory tree (e.g. /usr/local/lib/python2.7/dist-packages on Ubuntu) from Ansible's (e.g. /usr/lib/python2.7/dist-packages/ansible still on Ubuntu). As a consequence, ansible-playbook command will fail with: ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path. probably pointing on a task depending on a module present in requirements.txt (i.e. "unseal vault"). One way of solving this would be to uninstall the Ansible package and then, to install it via pip but it is not always possible. A workaround consists of setting ANSIBLE_LIBRARY and ANSIBLE_MODULE_UTILS environment variables respectively to the ansible/modules and ansible/module_utils subdirectories of pip packages installation location, which can be found in the Location field of the output of pip show [package] before executing ansible-playbook . Vagrant For Vagrant we need to install python dependencies for provisioning tasks. Check if Python and pip are installed: python -V && pip -V If this returns the version of the software, you're good to go. If not, download and install Python from here https://www.python.org/downloads/source/ Install the necessary requirements sudo pip install -r requirements.txt vagrant up Documents Requirements Kubespray vs ... Getting started Ansible inventory and tags Integration with existing ansible repo Deployment data variables DNS stack HA mode Network plugins Vagrant install CoreOS bootstrap Debian Jessie setup openSUSE setup Downloaded artifacts Cloud providers OpenStack AWS Azure vSphere Large deployments Upgrades basics Roadmap Supported Linux Distributions Container Linux by CoreOS Debian Jessie, Stretch, Wheezy Ubuntu 16.04, 18.04 CentOS/RHEL 7 Fedora 28 Fedora/CentOS Atomic openSUSE Leap 42.3/Tumbleweed Note: Upstart/SysV init based OS types are not supported. Supported Components Core kubernetes v1.11.3 etcd v3.2.18 docker v17.03 (see note) rkt v1.21.0 (see Note 2) Network Plugin calico v3.1.3 canal (given calico/flannel versions) cilium v1.2.0 contiv v1.1.7 flanneld v0.10.0 weave v2.4.1 Application cephfs-provisioner v2.1.0-k8s1.11 cert-manager v0.5.0 coredns v1.2.2 ingress-nginx v0.19.0 Note: kubernetes doesn't support newer docker versions ("Version 17.03 is recommended... Versions 17.06+ might work, but have not yet been tested and verified by the Kubernetes node team" cf. Bootstrapping Clusters with kubeadm ). Among other things kubelet currently breaks on docker's non-standard version numbering (it no longer uses semantic versioning). To ensure auto-updates don't break your cluster look into e.g. yum versionlock plugin or apt pin). Note 2: rkt support as docker alternative is limited to control plane (etcd and kubelet). Docker is still used for Kubernetes cluster workloads and network plugins' related OS services. Also note, only one of the supported network plugins can be deployed for a given single cluster. Requirements Ansible v2.4 (or newer) and python-netaddr is installed on the machine that will run Ansible commands Jinja 2.9 (or newer) is required to run the Ansible Playbooks The target servers must have access to the Internet in order to pull docker images. The target servers are configured to allow IPv4 forwarding . Your ssh key must be copied to all the servers part of your inventory. The firewalls are not managed , you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall. If kubespray is ran from non-root user account, correct privilege escalation method should be configured in the target servers. Then the ansible_become flag or command parameters --become or -b should be specified. Network Plugins You can choose between 6 network plugins. (default: calico , except Vagrant uses flannel ) flannel : gre/vxlan (layer 2) networking. calico : bgp (layer 3) networking. canal : a composition of calico and flannel plugins. cilium : layer 3/4 networking (as well as layer 7 to protect and secure application protocols), supports dynamic insertion of BPF bytecode into the Linux kernel to implement security services, networking and visibility logic. contiv : supports vlan, vxlan, bgp and Cisco SDN networking. This plugin is able to apply firewall policies, segregate containers in multiple network and bridging pods onto physical networks. weave : Weave is a lightweight container overlay network that doesn't require an external K/V database cluster. (Please refer to weave troubleshooting documentation ). The choice is defined with the variable kube_network_plugin . There is also an option to leverage built-in cloud provider networking instead. See also Network checker . Community docs and resources kubernetes.io/docs/getting-started-guides/kubespray/ kubespray, monitoring and logging by @gregbkr Deploy Kubernetes w/ Ansible & Terraform by @rsmitty Deploy a Kubernetes Cluster with Kubespray (video) Tools and projects on top of Kubespray Digital Rebar Provision Fuel-ccp-installer Terraform Contrib CI Tests CI/end-to-end tests sponsored by Google (GCE) See the test matrix for details.
来源:OSCHINA
发布时间:2018-09-21 22:45:00
通过前面Clouder课程的学习,或许你已经掌握了在云服务器上发布和部署静态网页的方法,那么如何搭建一个可以随时更新内容的动态网站?通过本课程的学习,你将掌握如何在云端搭建全世界使用最多的WordPress网站的方法,并学会网站自定义、管理的操作,来实验你想要的功能。 课程链接: 网站建设:简单动态网站搭建 学员受益: 零基础建站:从零开始,一步步教你搭建可以更新内容的动态网站 举一反三:通过网站主题管理和功能添加,可以将网站扩展为个人博客、小型门户、企业网站、视频网站等 认证证书:考试通过即可获得证书,证明自己拥有云平台建站的能力 课时介绍: 课程介绍 网站搭建的类型 动态网站的实现方式 搭建网站运行环境 部署与安装WordPress网站程序 云上WordPress网站的管理 云上WordPress网站的优化 【在线实验】云上快速搭建WordPress网站 更多精品课程: 阿里云大学官网(阿里云大学 - 官方网站,云生态下的创新人才工场)
来源:OSCHINA
发布时间:2018-09-21 14:34:00
简介 1.分布式数据库中间件 DDM 分布式数据库中间件(Distributed Database Middleware) 是解决数据库容量、性能瓶颈和分布式扩展问题的中间件服务,提供分库分表、读写分离、弹性扩容等能力,应对海量数据的高并发访问场景,有效提升数据库读写性能。 2.MySQL Router mysql-router是mysql官方的轻量级的中间件,用于取代MySQL Proxy应用程序像访问MySQL一样访问MySQL Router,由MySQL Router将数据转发给后端的DDM节点,实现Sidecar模式负载均衡。 Sidecar模式是一种从应用程序本身剥离应用程序功能作为单独进程的方法。此模式允许我们向应用无侵入添加多种功能,从而无需向应用程序添加其他配置代码。建议MySQL Router与应用程序部署在同一台机器做Sidecar模式负载均衡,相对于服务端形式的负载均衡,Sidecar模式实现负载均衡可以缩短调用链路,减少服务端中心节点的压力,去中心化,使用更加可靠更加高效。 部署Mysql-Router服务 # 解压安装程序文件 tar -xzvf mysql-router-8.0.11-linux-glibc2.12-x86-64bit.tar.gz # 重命名安装文件夹 mv mysql-router-8.0.11-linux-glibc2.12-x86-64bit /usr/local/mysqlrouter # 创建日志和配置相关文件存放目录 cd /usr/local/mysqlrouter mkdir logs mkdir etc # 利用模板文件创建配置文件 cp /usr/local/mysqlrouter/share/doc/mysqlrouter/sample_mysqlrouter.conf ./etc/mysqlrouter.conf # 启动 mysql router /usr/local/mysqlrouter/bin/mysqlrouter -c /usr/local/mysqlrouter/etc/mysqlrouter.conf & 配置文件详解 首先,获取DDM连接串,如下图所示: 下面详细介绍mysql-router三种配置方式: 01 作为中心代理节使用 mysql-router绑定IP不限制,即监听所有ip,任意节点都可以访问,作为数据库访问代理,轮询DDM各个节点。其中,destinations为上文获得的DDM连接串。 vi /usr/local/mysqlrouter/etc/mysqlrouter.conf [DEFAULT] logging_folder = /usr/local/mysqlrouter/log/ plugin_folder = /usr/local/mysqlrouter/lib/mysqlrouter/ config_folder = /usr/local/mysqlrouter/etc/ runtime_folder = /usr/local/mysqlrouter/run/ [logger] level = INFO # 负载均衡配置 [routing:balancing] # 绑定的IP地址 bind_address=0.0.0.0 # 监听的端口 bind_port = 7002 # 连接超时时间(秒) connect_timeout = 3 # 最大连接数 max_connections = 100 # 后端服务器地址.默认读进行轮询 destinations = 192.168.4.235:5066,192.168.4.231:5066 # 路由策略 routing_strategy=round-robin [keepalive] interval = 60 连接示例: [root @xxx ]# ./mysql -uddmtest -h128.11.2.2 -P7002 -p Enter password: mysql> 128.11.2.2为Mysql Router所在IP。 02 作为本地数据库代理使用 mysql-router绑定本地地址127.0.0.1,作为本地数据库访问代理,仅允许当前节点访问数据库。其要求需要访问数据库的应用与router部署在同一节点,更安全可靠。 vi /usr/local/mysqlrouter/etc/mysqlrouter.conf [DEFAULT] logging_folder = /usr/local/mysqlrouter/log/ plugin_folder = /usr/local/mysqlrouter/lib/mysqlrouter/ config_folder = /usr/local/mysqlrouter/etc/ runtime_folder = /usr/local/mysqlrouter/run/ [logger] level = INFO # 负载均衡配置 [routing:balancing] # 绑定的IP地址 bind_address=127.0.0.1 # 监听的端口 bind_port = 7002 # 连接超时时间(秒) connect_timeout = 3 # 最大连接数 max_connections = 100 # 后端服务器地址.默认读进行轮询 destinations = 192.168.4.235:5066,192.168.4.231:5066 # 路由策略 routing_strategy=round-robin [keepalive] interval = 60 连接示例: [root @xxx ]# ./mysql -uddmtest -h127.0.0.1 -P7002 -p Enter password: mysql> mysql客户端与Mysql Router在同一节点。 03 作为本地数据库代理,使用Unix sockets连接(推荐) mysql-router不绑定ip和端口,只使用Unix sockets连接,这样可以不经过tcp协议转发数据,只走操作系统socket通道,更加高效。其同样要求需要访问数据库的应用与router部署在同一节点,但是安全可靠,且高效。 vi etc/mysqlrouter.conf [DEFAULT] logging_folder = /usr/local/mysqlrouter/log/ plugin_folder = /usr/local/mysqlrouter/lib/mysqlrouter/ config_folder = /usr/local/mysqlrouter/etc/ runtime_folder = /usr/local/mysqlrouter/run/ [logger] level = INFO # 负载均衡配置 [routing:balancing] # 绑定的IP端口 socket = /tmp/mysqlrouter.sock # 连接超时时间(秒) connect_timeout = 3 # 最大连接数 max_connections = 100 # 后端服务器地址.默认读进行轮询 destinations = 192.168.4.235:5066,192.168.4.231:5066 # 路由策略 routing_strategy=round-robin [keepalive] interval = 60 其中,destinations为上文获得的DDM连接串 连接示例: [root @xxx ]# ./mysql -uddmtest -p -S /tmp/mysqlrouter.sock Enter password: mysql> mysql客户端与Mysql Router在同一节点。
来源:OSCHINA
发布时间:2018-09-21 10:27:00
如果您的应用程序是面向大量用户、会吸引大量流量,那么一个不变的目标一定是在高效满足用户需求的同时、不让用户感知到任何类似于“服务器繁忙!”的情况。这一诉求的典型解决方案是横向扩展部署,以便有多个应用程序容器可以为用户请求提供服务。但是,这种技术需要可靠的路由功能,需要可以有效地在多个服务器之间分配流量。本文分享的内容就是要解决负载均衡解决方案的问题。 Rancher 1.6是Docker和Kubernetes的容器编排平台,为负载均衡提供了功能丰富的支持。在Rancher 1.6中,用户可以通过使用开箱即用的HAProxy负载均衡器,来提供基于HTTP / HTTPS / TCP主机名/路径的路由。 而在本文中,我们将探讨如何在原生使用Kubernetes进行编排的Rancher 2.0平台上实现这些流行的负载均衡技术。 Rancher 2.0 负载均衡功能 通过Rancher 2.0,用户可以开箱即用地使用由NGINX Ingress Controller支持的原生Kubernetes Ingress功能进行7层负载均衡。因为Kubernetes Ingress仅支持HTTP和HTTPS协议,所以目前如果您使用的是Ingress支持,那么负载均衡仅限于上述这两种协议。 对于TCP协议,Rancher 2.0支持在部署Kubernetes集群的云上配置第4层TCP负载均衡器。后文中我们还将介绍如何通过ConfigMaps为TCP均衡配置NGINX Ingress Controller。 HTTP/HTTPS 负载均衡功能 在Rancher 1.6中,您添加了端口/服务规则以配置HAProxy负载均衡器,以均衡目标服务。您还可以配置基于主机名/路径的路由规则。 例如,下面让我们来看看一个在Rancher 1.6上启动了两个容器的服务。启动的容器正在监听私有80端口。 为了均衡两个容器之间的外部流量,我们可以为应用程序创建一个负载均衡器,如下所示。在这里,我们会配置负载均衡器,将进入端口80的所有流量转发到目标服务的容器端口,然后Rancher 1.6在负载均衡器服务上放置了一个方便的链接到公共端点。 Rancher 2.0提供了一种使用非常相似的、由NGINX Ingress Controller支持的、使用Kubernetes Ingress的负载均衡器功能。下文中我们一起来看看我们该如何做。 Rancher 2.0 Ingress Controller部署 Ingress只是一种规则,控制器组件会将这一规则应用于实际负载均衡器中。实际负载均衡器可以在集群外部运行,也可以在集群中部署。 通过RKE(Rancher Kubernetes安装程序),Rancher 2.0让用户可以开箱即用地在配置的集群上部署NGINX Ingress Controller和负载均衡器,以处理Kubernetes Ingress规则。请注意,NGINX Ingress Controller默认安装在RKE配置的集群上。通过云提供商(如GKE)配置的集群具有自己的Ingress Controller来配置负载均衡器。本文的范围仅适用于使用RKE安装的NGINX Ingress Controller。 RKE将NGINX Ingress Controller部署为Kubernetes DaemonSet——因此NGINX实例会部署在集群中的每个节点上。NGINX就像一个Ingress Controller,在整个集群中监听Ingress创建,它还会将自身配置为满足Ingress规则的负载均衡器。DaemonSet配置有hostNetwork以暴露两个端口——端口80和端口443。有关如何部署NGINX Ingress Controller DaemonSet和部署配置选项的详细信息,请参阅此处: https://rancher.com/docs/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/ 如果您是Rancher 1.6用户,那么将Rancher 2.0 Ingress Controller以DaemonSet的形式部署,会带来一些你需要知悉的重要的改变。 在Rancher 1.6中,您可以在堆栈中部署可扩展的负载均衡器服务。因此,如果您在Cattle环境中有四台主机,则可以部署一台规模为2的负载均衡器服务,并通过端口80在这两个主机IP地址上指向您的应用程序。然后,您还可以在剩余的两台主机上启动另一台负载均衡器,以通过端口80再次均衡不同的服务(因为负载均衡器使用不同的主机IP地址)。 Rancher 2.0 Ingress Controller是一个DaemonSet——因此它全局部署在所有可调度节点上,以便为整个Kubernetes集群提供服务。因此,在对Ingress规则进行编程时,你需要使用唯一的主机名和路径指向工作负载,因为负载均衡器节点IP地址和端口80/443是所有工作负载的公共访问点。 现在让我们看看如何使用Ingress将上述1.6示例部署到Rancher 2.0上。在Rancher UI上,我们可以导航到Kubernetes Cluster和Project,并选择【部署工作负载/Deploy Workloads】功能,在命名空间下部署所需镜像的工作负载。让我们将工作负载的规模设置为两个副本,如下所示: 以下是工作负载选项卡上部署和列出工作负载的方式: 要达到这两个pod之间的均衡,您必须创建Kubernetes Ingress规则。要创建此规则,请导航到您的集群和项目,然后选择“ 负载均衡”选项卡。 与Rancher 1.6中的服务/端口规则类似,您可以在此处指定针对工作负载的容器端口的规则。 基于主机和路径的路由 Rancher 2.0允许您添加基于主机名或URL路径的Ingress规则。根据您的规则,NGINX Ingress Controller将流量路由到多个目标工作负载。下面让我们看看如何使用相同的Ingress规范将流量路由到命名空间中的多个服务。比如如下两个在命名空间中部署的工作负载: 我们可以使用相同的主机名但不同的路径添加Ingress来均衡这两个工作负载的流量。 Rancher 2.0还为Ingress记录中的工作负载提供了方便的链接。如果配置外部DNS以对DNS记录进行编程,则可以将此主机名映射到Kubernetes Ingress地址。 Ingress地址是您的集群中Ingress Controller为您的工作负载分配的IP地址。您可以通过浏览此IP地址来达到工作负载。使用kubectl查看控制器分配入口地址。 您可以使用Curl来测试基于主机名/路径的路由规则是否正常工作,如下所示: 以下是使用基于主机名/路径的规则的Rancher 1.6配置规范,与2.0 Kubernetes Ingress YAML规范进行比较: HTTPS /证书选项 Rancher 2.0 Ingress功能还支持HTTPS协议。您可以在配置Ingress规则时上载证书并使用它们,如下所示: 添加Ingress规则时选择证书: Ingress限制 尽管Rancher 2.0支持HTTP- / HTTPS-基于主机名/路径的负载均衡,但要突出的一个重要区别是在为工作负载配置Ingress时需要使用唯一的主机名/路径。原因是Ingress功能仅允许将端口80/443用于路由,负载均衡器和Ingress Controller则可作为DaemonSet全局启动。 从最新的Rancher 2.x版本开始,Kubernetes Ingress不支持TCP协议,但我们将在下一节中讨论使用NGINX Ingress Controller的解决方法。 TCP负载均衡选项 四层负载均衡器 对于TCP协议,Rancher 2.0支持在部署Kubernetes集群的云提供程序中配置四层负载均衡器。为集群配置此负载均衡器设备后,Layer-4 Load Balancer在工作负载部署期间选择for port-mapping 选项时,Rancher会创建Load Balancer服务。此服务会让Kubernetes的相应云提供商配置负载均衡器设备。然后,此设备将外部流量路由到您的应用程序pod。请注意,上述功能需要该Kubernetes云提供商满足负载均衡器服务的要求,按此文档配置: https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/ 一旦负载均衡器配置成功,Rancher将在Rancher UI中为您的工作负载的公共端点提供一个链接。 通过ConfigMaps支持NGINX Ingress Controller TCP 如上所述,Kubernetes Ingress本身不支持TCP协议。因此,即使TCP不是NGINX的限制,也无法通过Ingress创建来配置NGINX Ingress Controller以进行TCP负载均衡。 但是,您可以通过创建一个Kubernetes ConfigMap,来使用NGINX的TCP负载均衡功能,具体可参阅这里: https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md。您可以创建Kuberenetes ConfigMap对象,来将pod配置参数存储为键值对,与pod镜像分开,更多细节可以参考这里: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/ 要配置NGINX以通过TCP暴露服务,您可以添加或更新命名空间tcp-services中的ConfigMap ingress-nginx。此命名空间还包含NGINX Ingress Controller pod。 ConfigMap条目中的密钥应该是您要公开访问的TCP端口,其值应为格式:。如上所示,我暴露了Default命名空间中存在的两个工作负载。例如,上面ConfigMap中的第一个条目告诉NGINX我想在外部端口上暴露运行在default命名空间上的myapp工作负载,并监听在外部端口6790上的私有端口80。 将这些条目添加到Configmap,将自动更新NGINX pod,以配置这些工作负载来进行TCP负载均衡。您可以执行部署在ingress-nginx命名空间中的这些pod,并查看如何在/etc/nginx/nginx.conf文件中配置这些TCP端口。:在NGINX配置/etc/nginx/nginx.conf更新后,应该可以使用公开的工作负载。如果它们不可访问,则可能必须使用NodePort服务来暴露TCP端口。 Rancher 2.0负载均衡的限制 Cattle提供了功能丰富的负载均衡器支持(详细介绍在此: https://rancher.com/docs/rancher/v1.6/en/cattle/adding-load-balancers/#load-balancers)。其中一些功能在Rancher 2.0中暂时没有等效功能: 当前NGINX Ingress Controller不支持SNI。 TCP负载均衡需要集群中的云提供程序启用的负载均衡器设备。Kubernetes上没有对TCP的Ingress支持。 只能通过Ingress为端口80/443配置HTTP / HTTPS路由。此外,Ingress Controller作为Daemonset进行全局部署,而不是作为可扩展服务启动。此外,用户无法随机分配外部端口来进行负载均衡。因此,用户需要确保它们配置的主机名/路径组合是唯一的,以避免使用相同的两个端口发生路由冲突。 无法指定端口规则优先级和排序。 Rancher 1.6增加了对draining后端连接和drain超时的支持。Rancher 2.0暂不支持此功能。 目前在Rancher 2.0中,不支持指定自定义粘性策略和自定义负载均衡器配置以附加到默认配置。原生Kubernetes对此有一定的支持,不过也只限于定制NGINX配置: https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/README/。 将负载均衡器配置从Docker Compose迁移到Kubernetes YAML? Rancher 1.6通过启动自己的微服务提供负载均衡器支持,该微服务启动并配置了HAProxy。用户添加的负载均衡器配置在rancher-compose.yml文件中指定,而不是标准的docker-compose.yml。Kompose工具适用于标准的docker-compose参数,但在本文的情况下,是无法解析Rancher负载均衡器配置结构的。截至目前,我们暂时无法使用Kompose工具将负载均衡器配置从Docker Compose转换为Kubernetes YAML。 结 论 由于Rancher 2.0基于Kubernetes并使用NGINX Ingress Controller(与Cattle使用HAProxy相比),因此原先Rancher 1.6中Cattle支持的一些负载均衡器的功能目前暂时没有直接等效功能。但是,Rancher 2.0支持流行的HTTP / HTTPS基于主机名/路径的路由,这种路由最常用于实际部署。还通过Kubernetes Load Balancer服务使用云提供商提供四层(TCP)支持。2.0中的负载均衡功能也具有类似的直观UI体验。 Kubernetes生态系统在不断发展,我相信我们能找到更多适合所有负载均衡细微差别的解决方案!
来源:OSCHINA
发布时间:2018-09-20 11:20:00
9 月19 日,2018杭州·云栖大会现场,杭州城市大脑2.0正式发布,管辖范围扩大28倍,覆盖面积增至420平方公里,相当于65个西湖大小。 ET 城市大脑等数字化城市解决方案,掀开了“杭州故事”的新篇章。今天的杭州,已从千年古城变为全球领先的数字化城市样本。 “这些新杭州故事,明天将会在更多城市发生。”阿里云总裁胡晓明在大会上表示,将以杭州为起点,向全球更多城市输出数字中国的“杭州方案”。 从人文胜地到科技之都 科技改变一座城 自古以来,杭州就是人文的代名词。“江南忆,最忆是杭州”诠释着人们对杭州的全部想象。 然而,今天的杭州不只是“人间天堂”,过去几年来,杭州在中国城市竞争中异军突起,变身为一座“科技之都”。 本次云栖大会上,杭州市政府联合阿里云等企业建设的杭州城市大脑2.0 正式发布。仅一年时间,城市大脑已成为杭州新基础设施:管辖范围扩大28倍,覆盖全城420平方公里,相当于65个西湖大小。通过交警手持的移动终端,大脑实时指挥200多名交警。在城市大脑的作用下,杭州交通拥堵率从2016年时的全国第5降至2018年的全国第57名。 除了依靠大数据、人工智能摆脱拥堵,今天的杭州,还是“移动支付之城”、“移动办事之城”、“智慧医疗之城”。 在杭州,出门办事“最多跑一次”,全市59 个政府部门368.32亿条信息汇聚在基于阿里云打造的政务服务平台上,市民可凭身份证一证通办296项事务。 在杭州,超过95 %的超市便利店、超过98%的出租车、5000余辆公交车都支持移动支付,堪称全球最大的移动支付之城。 在杭州,近年来,智慧医疗让近7000 万人次在杭州市属医院看病时间平均缩短2小时以上。 在杭州,成千上万的摊贩店主不再需要每天记账本、跑银行;跑航运、港运、路运的师傅不再需要花很多时间办数不清的证件;法院审理某些案子不再需要原告被告到场,甚至不需要书记员;去医院拍片子做CT ,不再需要去固定医院就诊,也不需要将片子全部打印出来;而创业公司也不再需要自己搭建服务器、数据中心,每天可能只需几十块钱就可以享受跟大公司一样的计算服务。 在杭州,一度遭遇低潮的百货业焕发新活力,银泰转型为大数据驱动的消费解决方案提供商。商超向新零售升级,世纪联华积极拥抱新技术。杭州银行携手云计算革新用户体验,具备了互联网金融能力。以吉利汽车为代表的汽车制造从营销到生产全流程数字化。 在传统工业制造领域,通过云计算与人工智能,沉默的数据被唤醒,中策橡胶、正泰新能源等工业企业的生产流程大幅优化,良品率上升带来利润增长。随着200 家工业企业相继入驻SupET工业互联网,杭州智造正在成为“新制造”的典型样本。 曾经,西雅图走出了亚马逊和微软两大科技巨头,反过来,两者也用数字化技术铸造了全新的西雅图。今天,杭州孕育了领先全球的云计算企业阿里云,而阿里巴巴则推动着千年古城杭州在新一轮数字化变革中走在前列。 “新杭州故事”只是刚刚开始 “ 我们今天讲述的新杭州故事只是开始,阿里云希望向全球更多城市输出新杭州背后的技术和实践。”在胡晓明看来,杭州被打造成数字中国的标杆城市,但新杭州故事的意义不止于杭州。 近年来,以阿里云为代表的科技企业走向海外,正在改变国际社会对中国的认知。国际社会已经将目光投入到中国科技带来的数字化转型上,科技领域的“中国方案”受到关注。区别于传统商品为主的国际贸易,中国技术走向世界不仅能为中国企业出海铺好“数字丝绸之路”,也能为当地经济增长带去新动能。 在中东,阿里云正在和有“中东MIT ”之称的哈利法大学共同探索解决能源领域的重大前沿问题;在传统工业大国德国,阿里云正在和世界知名的企业管理方案供应商SAP扩展全球合作伙伴关系,为全球企业提供更好的数字化转型解决方案;在非洲,阿里云正在和肯尼亚政府打造智能野生动物保护平台,保护更多珍稀动物;在奥运领域,阿里云正在和奥运转播服务公司OBS打造奥林匹克转播云,用视频云技术,让更多偏远地区可以更智能的方式观看奥运比赛视频;在马来西亚,ET城市大脑在杭州率先成功的特种车辆优先调度方案被吉隆坡引入,测试显示救护车到达现场的时间缩短了48.9%。未来,“杭州红绿灯”可能成为世界全新的一种红绿灯控制系统。 中国是全球数字化转型的试验场,而杭州是中国数字化浪潮的中心。100 年前,伦敦向世界输出了地铁,巴黎输出了下水道,纽约输出了电网。今天,中国杭州携手阿里云,正向世界贡献数字化城市方案。 杭州,是阿里云技术理想和家国情怀的起点和原点。 作者: 阿里云头条 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-09-19 16:04:00
带你了解Kubernetes架构的设计意图、Kubernetes系统的架构开发演进过程,以及背后的驱动原因。 1、背景 各种平台都会遇到一个不可回避的问题,即平台应该包含什么和不包含什么,Kubernetes也一样。Kubernetes作为一个部署和管理容器的平台,Kubernetes不能也不应该试图解决用户的所有问题。Kubernetes必须提供一些基本功能,用户可以在这些基本功能的基础上运行容器化的应用程序或构建它们的扩展。本文旨在明确Kubernetes架构的设计意图,描述Kubernetes的演进历程和未来的开发蓝图。 本文中,我们将描述Kubernetes系统的架构开发演进过程,以及背后的驱动原因。对于希望扩展或者定制kubernetes系统的开发者,其应该使用此文档作为向导,以明确可以在哪些地方,以及如何进行增强功能的实现。如果应用开发者需要开发一个大型的、可移植的和符合将来发展的kubernetes应用,也应该参考此文档,以了解Kubernetes将来的演化和发展。 从逻辑上来看,kubernetes的架构分为如下几个层次: 核心层(Nucleus): 提供标准的API和执行机制,包括基本的REST机制,安全、Pod、容器、网络接口和存储卷管理,通过接口能够对这些API和执进行扩展,核心层是必需的,它是系统最核心的一部分。 应用管理层(Application Management Layer ):提供基本的部署和路由,包括自愈能力、弹性扩容、服务发现、负载均衡和流量路由。此层即为通常所说的服务编排,这些功能都提供了默认的实现,但是允许进行一致性的替换。 治理层(The Governance Layer):提供高层次的自动化和策略执行,包括单一和多租户、度量、智能扩容和供应、授权方案、网络方案、配额方案、存储策略表达和执行。这些都是可选的,也可以通过其它解决方案实现。 接口层(The Interface Layer):提供公共的类库、工具、用户界面和与Kubernetes API交互的系统。 生态层(The Ecosystem):包括与Kubernetes相关的所有内容,严格上来说这些并不是Kubernetes的组成部分。包括CI/CD、中间件、日志、监控、数据处理、PaaS、serverless/FaaS系统、工作流、容器运行时、镜像仓库、Node和云提供商管理等。 2、系统分层 就像Linux拥有内核(kernel)、核心系统类库、和可选的用户级工具,kubernetes也拥有功能和工具的层次。对于开发者来说,理解这些层次是非常重要的。kubernetes APIs、概念和功能都在下面的层级图中得到体现。 2.1 核心层:API和执行(The Nucleus: API and Execution) 核心层包含最核心的API和执行机。 这些API和功能由上游的kubernetes代码库实现,由最小特性集和概念集所组成,这些特征和概念是系统上层所必需的。 这些由上游KubNeNETs代码库实现的API和函数包括建立系统的高阶层所需的最小特征集和概念集。这些内容被明确的地指定和记录,并且每个容器化的应用都会使用它们。开发人员可以安全地假设它们是一直存在的,这些内容应该是稳定和乏味的。 2.1.1 API和集群控制面板 Kubernetes集群提供了类似REST API的集,通过Kubernetes API server对外进行暴露,支持持久化资源的增删改查操作。这些API作为控制面板的枢纽。 遵循Kubernetes API约定(路径约定、标准元数据等)的REST API能够自动从共享API服务(认证、授权、审计日志)中收益,通用客户端代码能够与它们进行交互。 作为系统的最娣层,需要支持必要的扩展机制,以支持高层添加功能。另外,需要支持单租户和多租户的应用场景。核心层也需要提供足够的弹性,以支持高层能扩展新的范围,而不需要在安全模式方面进行妥协。 如果没有下面这些基础的API机和语义,Kubernetes将不能够正常工作: 认证(Authentication): 认证机制是非常关键的一项工作,在Kubernetes中需要通过服务器和客户端双方的认证通过。API server 支持基本认证模式 (用户命名/密码) (注意,在将来会被放弃), X.509客户端证书模式,OpenID连接令牌模式,和不记名令牌模式。通过kubeconfig支持,客户端能够使用上述各种认证模式。第三方认证系统可以实现TokenReview API,并通过配置认证webhook来调用,通过非标准的认证机制可以限制可用客户端的数量。 1、The TokenReview API (与hook的机制一样) 能够启用外部认证检查,例如Kubelet 2、Pod身份标识通过”service accounts“提供 3、The ServiceAccount API,包括通过控制器创建的默认ServiceAccount保密字段,并通过接入许可控制器进行注入。 授权(Authorization):第三方授权系统可以实现SubjectAccessReview API,并通过配置授权webhook进行调用。 1、SubjectAccessReview (与hook的机制一样), LocalSubjectAccessReview, 和SelfSubjectAccessReview APIs能启用外部的许可检查,诸如Kubelet和其它控制器。 REST 语义、监控、持久化和一致性保证、API版本控制、违约、验证 1、NIY:需要被解决的API缺陷: 2、混淆违约行为 3、缺少保障 4、编排支持 5、支持事件驱动的自动化 6、干净卸载 NIY: 内置的准入控制语义、同步准入控制钩子、异步资源初始化 — 发行商系统集成商,和集群管理员实现额外的策略和自动化 NIY:API注册和发行、包括API聚合、注册额外的API、发行支持的API、获得支持的操作、有效载荷和结果模式的详细信息。 NIY:ThirdPartyResource和ThirdPartyResourceData APIs (或她们的继承者),支持第三方存储和扩展API。 NIY:The Componentstatuses API的可扩展和高可用的替代,以确定集群是否完全体现和操作是否正确:ExternalServiceProvider (组件注册) The Endpoints API,组件增持需要,API服务器端点的自我发布,高可用和应用层目标发行 The Namespace API,用户资源的范围,命名空间生命周期(例如:大量删除) The Event API,用于对重大事件的发生进行报告,例如状态改变和错误,以及事件垃圾收集 NIY:级联删除垃圾收集器、finalization, 和orphaning NIY: 需要内置的add-on的管理器 ,从而能够自动添加自宿主的组件和动态配置到集群,在运行的集群中提取出功能。 1、Add-ons应该是一个集群服务,作为集群的一部分进行管理 2、它们可以运行在kube-system命名空间,这么就不会与用户的命名进行冲突 API server作为集群的网关。根据定义,API server必需能够被集群外的客户端访问,而Node和Pod是不被集群外的客户端访问的。客户端认证API server,并使用API server作为堡垒和代理/通道来通过/proxy和/portforward API访问Node和Pod等Clients authenticate the API server and also use it TBD:The CertificateSigningRequest API,能够启用认证创建,特别是kubele证书。 理想情况下,核心层API server江仅仅支持最小的必需的API,额外的功能通过聚合、钩子、初始化器、和其它扩展机制来提供。注意,中心化异步控制器以名为Controller Manager的独立进程运行,例如垃圾收集。 API server依赖下面的外部组件: 持久化状态存储 (etcd,或相对应的其它系统;可能会存在多个实例) API server可以依赖: 身份认证提供者 The TokenReview API实现者 实现者 The SubjectAccessReview API实现者 2.1.2 执行 在Kubernetes中最重要的控制器是kubelet,它是Pod和Node API的主要实现者,没有这些API的话,Kubernetes将仅仅只是由键值对存储(后续,API机最终可能会被作为一个独立的项目)支持的一个增删改查的REST应用框架。 Kubernetes默认执行独立的应用容器和本地模式。 Kubernetes提供管理多个容器和存储卷的Pod,Pod在Kubernetes中作为最基本的执行单元。 Kubelet API语义包括: The Pod API,Kubernetes执行单元,包括: 1、Pod可行性准入控制基于Pod API中的策略(资源请求、Node选择器、node/pod affinity and anti-affinity, taints and tolerations)。API准入控制可以拒绝Pod或添加额外的调度约束,但Kubelet才是决定Pod最终被运行在哪个Node上的决定者,而不是schedulers or DaemonSets。 2、容器和存储卷语义和生命周期 3、Pod IP地址分配(每个Pod要求一个可路由的IP地址) 4、将Pod连接至一个特定安全范围的机制(i.e., ServiceAccount) 5、存储卷来源: 5.1、emptyDir 5.2、hostPath 5.3、secret 5.4、configMap 5.5、downwardAPI 5.6、NIY:容器和镜像存储卷 (and deprecate gitRepo) 5.7、NIY:本地存储,对于开发和生产应用清单不需要复杂的模板或独立配置 5.8、flexVolume (应该替换内置的cloud-provider-specific存储卷) 6、子资源:绑定、状态、执行、日志、attach、端口转发、代理 NIY:可用性和引导API 资源检查点 容器镜像和日志生命周期 The Secret API,启用第三方加密管理 The ConfigMap API,用于组件配置和Pod引用 The Node API,Pod的宿主 1、在一些配置中,可以仅仅对集群管理员可见 Node和pod网络,业绩它们的控制(路由控制器) Node库存、健康、和可达性(node控制器) 1、Cloud-provider-specific node库存功能应该被分成特定提供者的控制器 pod终止垃圾收集 存储卷控制器 1、Cloud-provider-specific attach/detach逻辑应该被分成特定提供者的控制器,需要一种方式从API中提取特定提供者的存储卷来源。 The PersistentVolume API 1、NIY:至少被本地存储所支持 The PersistentVolumeClaim API 中心化异步功能,诸如由Controller Manager执行的pod终止垃圾收集。 当前,控制过滤器和kubelet调用“云提供商”接口来询问来自于基础设施层的信息,并管理基础设施资源。然而,kubernetes正在努力将这些触摸点(问题)提取到外部组件中,不可满足的应用程序/容器/OS级请求(例如,PODS,PersistentVolumeClaims)作为外部“动态供应”系统的信号,这将使基础设施能够满足这些请求,并使用基础设施资源(例如,Node、和PersistentVolumes)在Kubernetes进行表示,这样Kubernetes可以将请求和基础设施资源绑定在一起。 对于kubelet,它依赖下面的可扩展组件: 镜像注册 容器运行时接口实现 容器网络接口实现 FlexVolume 实现(”CVI” in the diagram) 以及可能依赖: NIY:第三方加密管理系统(例如:Vault) NIY:凭证创建和转换控制器 2.2 应用层:部署和路由 应用管理和组合层,提供自愈、扩容、应用生命周期管理、服务发现、负载均衡和路由— 也即服务编排和service fabric。这些API和功能是所有Kubernetes分发所需要的,Kubernetes应该提供这些API的默认实现,当然可以使用替代的实现方案。没有应用层的API,大部分的容器化应用将不能运行。 Kubernetes’s API提供类似IaaS的以容器为中心的基础单元,以及生命周期控制器,以支持所有工作负载的编排(自愈、扩容、更新和终止)。这些应用管理、组合、发现、和路由API和功能包括: 默认调度,在Pod API中实现调度策略:资源请求、nodeSelector、node和pod affinity/anti-affinity、taints and tolerations. 调度能够作为一个独立的进度在集群内或外运行。 NIY:重新调度器 ,反应和主动删除已调度的POD,以便它们可以被替换并重新安排到其他Node 持续运行应用:这些应用类型应该能够通过声明式更新、级联删除、和孤儿/领养支持发布(回滚)。除了DaemonSet,应该能支持水平扩容。 1、The Deployment API,编排更新无状态的应用,包括子资源(状态、扩容和回滚) 2、The DaemonSet API,集群服务,包括子资源(状态) 3、The StatefulSet API,有状态应用,包括子资源(状态、扩容) 4、The PodTemplate API,由DaemonSet和StatefulSet用来记录变更历史 终止批量应用:这些应该包括终止jobs的自动剔除(NIY) 1、The Job API (GC discussion) 2、The CronJob API 发现、负载均衡和路由 1、The Service API,包括集群IP地址分配,修复服务分配映射,通过kube-proxy或者对等的功能实现服务的负载均衡,自动化创建端点,维护和删除。NIY:负载均衡服务是可选的,如果被支持的化,则需要通过一致性的测试。 2、The Ingress API,包括internal L7 (NIY) 3、服务DNS。DNS使用official Kubernetes schema。 应用层可以依赖: 身份提供者 (集群的身份和/或应用身份) NIY:云提供者控制器实现 Ingress controller(s) 调度器和重新调度器的替代解决方案 DNS服务替代解决方案 kube-proxy替代解决方案 工作负载控制器替代解决方案和/或辅助,特别是用于扩展发布策略 2.3 治理层:自动化和策略执行 策略执行和高层自动化。这些API和功能是运行应用的可选功能,应该挺其它的解决方案实现。 每个支持的API/功能应用作为企业操作、安全和治理场景的一部分。 需要为集群提供可能的配置和发现默认策略,至少支持如下的用例: 单一租户/单一用户集群 多租户集群 生产和开发集群 Highly tenanted playground cluster 用于将计算/应用服务转售给他人的分段集群 需要关注的内容: 1、资源使用 2、Node内部分割 3、最终用户 4、管理员 5、服务质量(DoS) 自动化APIs和功能: 度量APIs (水平/垂直自动扩容的调度任务表) 水平Pod自动扩容API NIY:垂直Pod自动扩容API(s) 集群自动化扩容和Node供应 The PodDisruptionBudget API 动态存储卷供应,至少有一个出厂价来源类型 1、The StorageClass API,至少有一个默认存储卷类型的实现 动态负载均衡供应 NIY:PodPreset API NIY:service broker/catalog APIs NIY:Template和TemplateInstance APIs 策略APIs和功能: 授权:ABAC和RBAC授权策略方案 1、RBAC,实现下面的API:Role, RoleBinding, ClusterRole, ClusterRoleBinding The LimitRange API The ResourceQuota API The PodSecurityPolicy API The ImageReview API The NetworkPolicy API 管理层依赖: 网络策略执行机制 替换、水平和垂直Pod扩容 集群自动扩容和Node提供者 动态存储卷提供者 动态负载均衡提供者 度量监控pipeline,或者它的替换 服务代理 2.4 接口层:类库和工具 这些机制被建议用于应用程序版本的分发,用户也可以用其进行下载和安装。它们包括Kubernetes官方项目开发的通用的类库、工具、系统、界面,它们可以用来发布。 Kubectl — kubectl作为很多客户端工具中的一种,Kubernetes的目标是使Kubectl更薄,通过将常用的非平凡功能移动到API中。这是必要的,以便于跨Kubernetes版本的正确操作,并促进API的扩展性,以保持以API为中心的Kubernetes生态系统模型,并简化其它客户端,尤其是非GO客户端。 客户端类库(例如:client-go, client-python) 集群联邦(API server, controllers, kubefed) Dashboard Helm 这些组件依赖: Kubectl扩展 Helm扩展 2.5 生态 在有许多领域,已经为Kubernetes定义了明确的界限。虽然,Kubernetes必须提供部署和管理容器化应用需要的通用功能。但作为一般规则,在对Kubernete通用编排功能进行补足的功能领域,Kubernetes保持了用户的选择。特别是那些有自己的竞争优势的区域,特别是能够满足不同需求和偏好的众多解决方案。Kubernetes可以为这些解决方案提供插件API,或者可以公开由多个后端实现的通用API,或者公开此类解决方案可以针对的API。有时,功能可以与Kubernetes干净地组合在而不需要显式接口。 此外,如果考虑成为Kubernetes的一部分,组件就需要遵循Kubernetes设计约定。例如,主要接口使用特定域语言的系统(例如,Puppet、Open Policy Agent)与Kubenetes API的方法不兼容,可以与Kubernetes一起使用,但不会被认为是Kubernetes的一部分。类似地,被设计用来支持多平台的解决方案可能不会遵循Kubernetes API协议,因此也不会被认为是Kubernetes的一部分。 内部的容器镜像:Kubernetes不提供容器镜像的内容。 如果某些内容被设计部署在容器镜像中,则其不应该直接被考虑作为Kubernetes的一部分。例如,基于特定语言的框架。 在Kubernetes的顶部 1、持久化集成和部署(CI/CD):Kubernetes不提供从源代码到镜像的能力。Kubernetes 不部署源代码和不构建应用。用户和项目可以根据自身的需要选择持久化集成和持久化部署工作流,Kubernetes的目标是方便CI/CD的使用,而不是命令它们如何工作。 2、应用中间件:Kubernetes不提供应用中间件作为内置的基础设施,例如:消息队列和SQL数据库。然而,可以提供通用目的的机制使其能够被容易的提供、发现和访问。理想的情况是这些组件仅仅运行在Kubernetes上。 3、日志和监控:Kubernetes本身不提供日志聚合和综合应用监控的能力,也没有遥测分析和警报系统,虽然日志和监控的机制是Kubernetes集群必不可少的部分。 4、数据处理平台:在数据处理平台方面,Spark和Hadoop是还有名的两个例子,但市场中还存在很多其它的系统。 5、特定应用运算符:Kubernetes支持通用类别应用的工作负载管理。 6、平台即服务 Paas:Kubernetes为Paas提供基础。 7、功能即服务 FaaS:与PaaS类似,但Faa侵入容器和特定语言的应用框架。 8、工作量编排: “工作流”是一个非常广泛的和多样化的领域,通常针对特定的用例场景(例如:数据流图、数据驱动处理、部署流水线、事件驱动自动化、业务流程执行、iPAAS)和特定输入和事件来源的解决方案,并且通常需要通过编写代码来实现。 9、配置特定领域语言:特定领域的语言不利于分层高级的API和工具,它们通常具有有限的可表达性、可测试性、熟悉性和文档性。它们复杂的配置生成,它们倾向于在互操作性和可组合性间进行折衷。它们使依赖管理复杂化,并经常颠覆性的抽象和封装。 10、Kompose:Kompose是一个适配器工具,它有助于从Docker Compose迁移到Kubernetes ,并提供简单的用例。Kompose不遵循Kubernetes约定,而是基于手动维护的DSL。 11、ChatOps:也是一个适配器工具,用于聊天服务。 支撑Kubernetes 1、容器运行时:Kubernetes本身不提供容器运行时环境,但是其提供了接口,可以来插入所选择的容器运行时。 2、镜像仓库:Kubernetes本身不提供容器的镜像,可通过Harbor、Nexus和docker registry等搭建镜像仓库,以为集群拉取需要的容器镜像。 3、集群状态存储:用于存储集群运行状态,例如默认使用Etcd,但也可以使用其它存储系统。 4、网络:与容器运行时一样,Kubernetes提供了接入各种网络插件的容器网络接口(CNI)。 5、文件存储:本地文件系统和网络存储 6、Node管理:Kubernetes既不提供也不采用任何综合的机器配置、维护、管理或自愈系统。通常针对不同的公有/私有云,针对不同的操作系统,针对可变的和不可变的基础设施。 7、云提供者:IaaS供应和管理。 8、集群创建和管理:社区已经开发了很多的工具,利润minikube、kubeadm、bootkube、kube-aws、kops、kargo, kubernetes-anywhere等待。 从工具的多样性可以看出,集群部署和管理(例如,升级)没有一成不变的解决方案。也就是说,常见的构建块(例如,安全的Kubelet注册)和方法(特别是自托管)将减少此类工具中所需的自定义编排的数量。 后续,希望通过建立Kubernetes的生态系统,并通过整合相关的解决方案来满足上述需求。 矩阵管理 选项、可配置的默认、扩展、插件、附加组件、特定于提供者的功能、版本管理、特征发现和依赖性管理。 Kubernetes不仅仅是一个开源的工具箱,而且是一个典型集群或者服务的运行环境。 Kubernetes希望大多数用户和用例能够使用上游版本,这意味着Kubernetes需要足够的可扩展性,而不需要通过重建来处理各种场景。 虽然在可扩展性方面的差距是代码分支的主要驱动力,而上游集群生命周期管理解决方案中的差距是当前Kubernetes分发的主要驱动因素,可选特征的存在(例如,alpha API、提供者特定的API)、可配置性、插件化和可扩展性使概念不可避免。 然而,为了使用户有可能在Kubernetes上部署和管理他们的应用程序,为了使开发人员能够在Kubernetes集群上构建构建Kubernetes扩展,他们必须能够对Kubernetes集群或分发提供一个假设。在基本假设失效的情况下,需要找到一种方法来发现可用的功能,并表达功能需求(依赖性)以供使用。 集群组件,包括add-ons,应该通过组件注册 API进行注册和通过/componentstatuses进行发现。 启用内置API、聚合API和注册的第三方资源,应该可以通过发现和OpenAPI(Savigj.JSON)端点来发现。如上所述,LoadBalancer类型服务的云服务提供商应该确定负载均衡器API是否存在。 类似于StorageClass,扩展和它们的选项应该通过FoeClass资源进行注册。但是,使用参数描述、类型(例如,整数与字符串)、用于验证的约束(例如,ranger或regexp)和默认值,从扩展API中引用fooClassName。这些API应该配置/暴露相关的特征的存在,例如动态存储卷供应(由非空的storageclass.provisioner字段指示),以及标识负责的控制器。需要至少为调度器类、ingress控制器类、Flex存储卷类和计算资源类(例如GPU、其他加速器)添加这样的API。 假设我们将现有的网络存储卷转换为flex存储卷,这种方法将会覆盖存储卷来源。在将来,API应该只提供通用目的的抽象,即使与LoadBalancer服务一样,抽象并不需要在所有的环境中都实现(即,API不需要迎合最低公共特性)。 NIY:需要为注册和发现开发下面的机制: 准入控制插件和hooks(包括内置的APIs) 身份认证插件 授权插件和hooks 初始化和终结器 调度器扩展 Node标签和集群拓扑 NIY:单个API和细粒度特征的激活/失活可以通过以下机制解决: 所有组件的配置正在从命令行标志转换为版本化配置。 打算将大部分配置数据存储在配置映射(ConfigMaps)中,以便于动态重新配置、渐进发布和内省性。 所有/多个组件共同的配置应该被分解到它自己的配置对象中。这应该包括特征网关机制。 应该为语义意义上的设置添加API,例如,在无响应节点上删除Pod之前需要等待的默认时间长度。 NIY:版本管理操作的问题,取决于多个组件的升级(包括在HA集群中的相同组件的副本),应该通过以下方式来解决: 为所有新的特性创建flag网关 总是在它们出现的第一个小版本中,默认禁用这些特性, 提供启用特性的配置补丁; 在接下来的小版本中默认启用这些特性 NIY:我们还需要一个机制来警告过时的节点,和/或潜在防止Master升级(除了补丁发布),直到/除非Node已经升级。 NIY:字段级版本管理将有助于大量激活新的和/或alpha API字段的解决方案,防止不良写入过时的客户端对新字段的阻塞,以及非alpha API的演进,而不需要成熟的API定义的扩散。 Kubernetes API server忽略不支持的资源字段和查询参数,但不忽略未知的/未注册的API(注意禁用未实现的/不活动的API)。这有助于跨多个版本的集群重用配置,但往往会带来意外。Kubctl支持使用服务器的Wagger/OpenAPI规范进行可选验证。这样的可选验证,应该由服务器(NYY)提供。此外,为方便用户,共享资源清单应该指定Kubernetes版本最小的要求,这可能会被kubectl和其他客户端验证。 服务目录机制(NIY)应该能够断言应用级服务的存在,例如S3兼容的群集存储。 与安全相关的系统分层 为了正确地保护Kubernetes集群并使其能够安全扩展,一些基本概念需要由系统的组件进行定义和约定。最好从安全的角度把Kubernetes看作是一系列的环,每个层都赋予连续的层功能去行动。 用于存储核心API的一个或者多个数据存储系统(etcd) 核心APIs 高度可信赖资源的APIs(system policies) 委托的信任API和控制器(用户授予访问API /控制器,以代表用户执行操作),无论是在集群范围内还是在更小的范围内 在不同范围,运行不受信任/作用域API和控制器和用户工作负载 当较低层依赖于更高的层时,它会使安全模型崩溃,并使系统变得更加复杂。管理员可以选择这样做以获得操作简单性,但这必须是有意识的选择。一个简单的例子是etcd:可以将数据写入etcd的任何组件现在都在整个集群上,任何参与者(可以破坏高度信任的资源)都几乎可以进行逐步升级。为每一层的进程,将上面的层划分成不同的机器集(etcd-> apiservers +控制器->核心安全扩展->委托扩展- >用户工作负载),即使有些可能在实践中崩溃。 如果上面描述的层定义了同心圆,那么它也应该可能存在重叠或独立的圆-例如,管理员可以选择一个替代的秘密存储解决方案,集群工作负载可以访问,但是平台并不隐含地具有访问权限。这些圆圈的交点往往是运行工作负载的机器,并且节点必须没有比正常功能所需的特权更多的特权。 最后,在任何层通过扩展添加新的能力,应该遵循最佳实践来传达该行为的影响。 当一个能力通过扩展被添加到系统时,它有什么目的? 使系统更加安全 为集群中的每一个人,启用新的“生产质量”API 在集群的子集上自动完成一个公共任务 运行一个向用户提供API的托管工作负载(spark、数据库、etcd) 它们被分为三大类: 1、集群所需的(因此必须在内核附近运行,并在存在故障时导致操作权衡) 2、暴露于所有集群用户(必须正确地租用) 3、暴露于集群用户的子集(像传统的“应用程序”工作负载运行) 如果管理员可以很容易地被诱骗,在扩展期间安装新的群集级安全规则,那么分层被破坏,并且系统是脆弱的。 英文原文: https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md 本文译者: 季向远,北京神舟航天软件技术有限公司产品经理。 本文版权归原作者所有。本文版权归原作者所有。
来源:OSCHINA
发布时间:2018-09-19 10:05:00
kolla是从openstack孵化出的一个项目,kolla项目可以制作镜像包括openstack、ceph等容器镜像, ansible是自动化部署工具,执行playbook中的任务。 kolla-ansible是容器部署工具,部署openstack和ceph;kolla-ansible部署的容器镜像可以是kolla构建的,也可以是从docker register下载来的(本文部署使用kolla-ansible部署ceph采用从docker register下载镜像的方式部署)。 一、节点规划 主机名 ip 角色 localhost 172.16.134.43 master节点,安装kolla-ansible node58 172.16.134.58 ceph节点,至少有一块osd使用的磁盘 node59 node61 172.16.134.59 172.16.134.61 ceph节点,至少有一块osd使用的磁盘 ceph节点,至少有一块osd使用的磁盘 二、搭建master节点 1、安装docker yum install -y yum-utils device-mapper-persistent-data lvm2 yum install docker-ce -y 2、master和ceph节点之间解决互信 ssh-keygen ssh-copy-id root@172.16.134.58 ssh-copy-id root@172. 16.134.59 ssh-copy-id root@172. 16.134.61 3、安装kolla-ansible依赖包 yum -y install epel-release yum install -y python-pip ansible yum install -y python-devel libffi-devel openssl-devel gcc python-setuptools git 4、修改pip源: mkdir -p ~/.pip tee ~/.pip/pip.conf <<-'EOF' [global] trusted-host= mirrors.aliyun.com index-url= http://mirrors.aliyun.com/pypi/simple/ EOF 5、升级pip: pip install -U pip 6、下载kolla-ansible源码并安装 git clone https://github.com/openstack/kolla-ansible.git -b stable/queens cd kolla-ansilbe pip install -r requirements.txt -r test-requirements.txt pip install . -i http://mirrors.aliyun.com/pypi/simple/ 7、复制相关文件 cp -r etc/kolla /etc/kolla/ cp ansible/inventory/* /home 8、生成密码 kolla-genpwd 9、设置docker mkdir /etc/systemd/system/docker.service.d 编辑kolla.conf文件 vim /etc/systemd/system/docker.service.d/kolla.conf [Service] MountFlags=shared 编辑daemon.json文件 vi /etc/docker/daemon.json { "registry-mirrors": ["https://ebu037tr.mirror.aliyuncs.com"], "insecure-registries": ["docker-registries"] } 注意:docker-registries为docker镜像服务器,在部署过程中,kolla-ansible会从docker服务器上拉取所需要的镜像,该docker镜像服务器要有ceph各组件的镜像。 在ceph节点上也要用docker login {docker-registries},登陆到docker服务器,否则在部署过程中会出现认证错误。 10、重启docker服务 systemctl daemon-reload systemctl restart docker 11、修改/etc/hosts文件,填入ceph节点 三、ceph节点环境配置(在三个ceph节点上执行同样的操作) 1、禁用节点放火墙,安全策略等 [root@node58 ~]vim ~/init.sh #!/bin/sh sed -i 's/SELINUX=.*/SELINUX=Disabled/g' /etc/selinux/config echo '' > /etc/resolv.conf echo nameserver 114.114.114.114 >> /etc/resolv.conf echo search novalocal >> /etc/resolv.conf echo " net.ipv4.ip_forward = 1 ">> /etc/sysctl.conf&&sysctl -p yum install vim wget -y systemctl stop firewalld systemctl disable firewalld ----------------------------------------------------------- [root@node58 ~]# sh init.sh 2、节点配置时间同步 [root@node58 ~]# yum install -y chrony [root@node58 ~]# vi /etc/chrony.conf server 0.cn.pool.ntp.org iburst server 1.cn.pool.ntp.org iburst server 2.cn.pool.ntp.org iburst server 3.cn.pool.ntp.org iburst 3、给ceph节点的磁盘打标签 [root@node58 ~]# parted /dev/sdb -s -- mklabel gpt mkpart KOLLA_CEPH_OSD_BOOTSTRAP 1 -1 四、部署ceph容器服务(在master节点执行) 1、修改kolla-ansible的配置文件 [root@node58 ~]# cat /etc/kolla/globals.yml|grep -v '^#'|grep -v '^$' --- kolla_install_type: "binary" openstack_release: "queens" kolla_internal_vip_address: "ip of master" docker_registry: "{docker-registries}" docker_namespace: "queens/kolla" docker_registry_username: "admin" docker_registry_password: "Harbor12345" network_interface: "ens33" enable_ceph: "yes" enable_haproxy: "no" enable_keystone: "no" enable_glance: "no" enable_neutron: "no" enable_heat: "no" enable_nova: "no" enable_horizon: "no" ceph_pool_type: "replicated" 注意:/etc/kolla/globals.yml文件会重载/usr/share/kolla-ansible/ansible/group_vars/all.yml文件,不需要安装的服务在all.yml中改成“no” 2、修改ansible的inventory文件 在[storage]下填入ceph节点的主机名,把其余section清空 6、部署ceph节点环境 kolla-ansible bootstrap-servers -i /home/multinode 7、检查和部署 kolla-ansible prechecks -i /home/multinode kolla-ansible deploy -i /home/multinode 8、测试(在ceph节点执行) docker exec ceph_mon ceph -s
来源:OSCHINA
发布时间:2018-10-22 17:03:00
我开发了一个Java应用,部署到云环境上之后,用postman测试发现不能按照我期望的工作,但是返回的消息对我没有任何帮助。 因为部署在云端的应用很难像本地Java应用一样调试,所以我打算用SLF4J在Java代码里添加一些日志,然后查看该Java应用在云端执行产生的日志来排查问题。 SLF4J的全称是Simple Logging Facade for Java, 即简单日志门面,这里的Facade实际上是面向对象的设计模式中的外观模式(Facade pattern)。SLF4J不是具体的日志解决方案,它本身不包含日志记录的具体实现,而是只提供一个外观给各种各样的日志系统,这样就给具体应用提供了很大的灵活度,使得最终用户在部署其应用时可以灵活选用其所希望的日志系统。 SLF4J的使用非常简单,在您的应用代码里将SLF4J的Logger和LoggerFactory导入: import org.slf4j.Logger; import org.slf4j.LoggerFactory; 然后在引用代码里用LoggerFactory获得logger实例: static private Logger logger = LoggerFactory.getLogger(XCDService.class); 然后用logger.info进行日志记录。 将加了SLF4J日志记录的代码重新上传到云平台上。我用的是SAP云平台。 登录SAP云平台的控制台,点击Logging标签页: 点Configure Loggers: 因为我的应用代码放在com.sap.service包下面,所以我根据这个包名进行过滤: 将这两个Logger对应的Log Level日志级别设置成INFO: 再次用postman请求部署在SAP云平台上的服务,然后去云平台控制台上查看生成的日志文件: 点击查看按钮即可看到日志的具体内容,一下子就定位出问题的原因了。我在服务器端的HTTP响应头字段Content-type设置的值为application/json,但是返回的JSON字符串不符合JSON格式规范。把这个bug改掉之后错误就解决了。 要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:
来源:OSCHINA
发布时间:2018-10-22 14:40:00
关于阿里云容器服务的详细内容: 阿里云容器服务使用教程 容器服务(Container Service)提供高性能可伸缩的容器应用管理服务,支持用 Docker 容器进行应用生命周期管理,提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务简化了容器管理集群的搭建工作,整合了阿里云虚拟化、存储、网络和安全能力,打造 Docker 云端最佳运行环境。 产品功能: 集群管理,灵活的地域和网络环境选择 用户可以根据自己的需求,选择不同的地域创建和删除集群。 可选择经典网络或专有网络 VPC 环境。 多种服务器托管方式 支持授权容器服务创建云服务器加入到指定集群。 支持将已购买的云服务器添加到指定集群。 一站式容器生命周期管理 网络:支持跨宿主机容器间互联,支持通过 container name 或 hostname 定义的域名互访。 存储:支持数据卷管理,支持 OSSFS 和文件存储(Network Attached Storage,简称 NAS)。 日志:支持日志自动采集和日志服务集成。 监控:支持容器级别和 VM 级别的监控。 调度:支持跨可用区高可用和异常节点的 reschedule 等策略。 路由:支持 4 层和 7 层的请求转发和后端绑定。 子账号:支持集群级别的 RAM 授权管理。 Docker 兼容性 兼容标准 Docker API。 兼容 Docker Swarm 1.2.8。 兼容 Docker Engine CE 17.06.2。 支持 Docker Compose V1/V2/V3。 阿里云环境特有的增值能力,更好的体验 整合专有网络 VPC,提供安全、高性能、支持混合云的部署方案。 扩展 Compose 模板定义,增强生命周期管理。 整合负载均衡,提供容器的访问能力。 高可用调度策略,轻松打通上下游交付流程 支持服务级别的亲和性策略和横向扩展。 支持跨可用区高可用和灾难恢复。 支持集群和应用管理的 OpenAPI,轻松对接持续集成和私有部署系统。 容器服务的基础架构其中: 集群管理服务:提供 Docker 集群管理和调度。 服务发现:提供 Docker 的状态等元数据存储。 Agent 通信服务:提供每台宿主机和集群管理服务之间的通信服务。 集群 API:对外暴露阿里云统一的 OpenAPI 能力。 服务 API:对外暴露兼容 Docker Swarm 的 API 能力。 更多精品课程: 阿里云大学官网( 阿里云大学 - 官方网站,云生态下的创新人才工场 )
来源:OSCHINA
发布时间:2018-10-22 14:04:00
PersistentVolume(简称PV)和PersistentVolumeClaim(简称PVC) PersistentVolume(持久卷,简称PV)是集群内,由管理员提供的网络存储的一部分。就像集群中的节点一 样,PV也是集群中的一种资源。它也像Volume一样,是一种volume插件,但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对 象,捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。 PersistentVolumeClaim(持久卷声明,简称PVC)是用户的一种存储请求。它和Pod类似,Pod消耗Node资源,而PVC消耗PV资源。Pod能够请求特定的资源(如CPU和内存)。PVC能够请求指定的大小和访问的模式(可以被映射为一次读写或者多次只读)。 PVC允许用户消耗抽象的存储资源,用户也经常需要各种属性(如性能)的PV。集群管理员需要提供各种各样、不同大小、不同访问模式的PV,而不用向用户暴露这些volume如何实现的细节。因为这种需求,就催生出一种StorageClass资源。 StorageClass提供了一种方式,使得管理员能够描述他提供的存储的等级。集群管理员可以将不同的等级映射到不同的服务等级、不同的后端策略。 供给 PV是集群中的资源,PVC是对这些资源的请求,同时也是这些资源的“提取证”。PV和PVC的交互遵循以下生命周期: 有两种PV提供的方式:静态和动态。 静态 集群管理员创建多个PV,它们携带着真实存储的详细信息,这些存储对于集群用户是可用的。它们存在于Kubernetes API中,并可用于存储使用。 apiVersion: v1 kind: PersistentVolume metadata: name: pv01 namespace: sit spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle nfs: server: 10.42.0.55 path: "/opt/public" 动态 当管理员创建的静态PV都不匹配用户的PVC时,集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass:PVC必须请求这样一个等级,而管理员必须已经创建和配置过这样一个等级,以备发生这种动态供给的情况。请求等级配置为“”的PVC,有效地禁用了它自身的动态供给功能。 Kubernetes 1.4 中加入了一个 新的 API 对象 StorageClass,可以定义多个 StorageClass 对象,并可以分别指定存储插件、设置参数,用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内,定义和提供不同类型的、不同参数的卷(相同或者不同的存储系统)。这样的设计还确保了最终用户在无需了解太多的情况下,有能力选择不同的存储选项。 这种场景比较常见的是使用在高级的私有云分布式存储或者公有云存储情况下,大多数是集成第三方的 举例:创建一个slow,另外一个fast的盘在谷歌云上 kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: slow provisioner: kubernetes.io/gce-pd parameters: type: pd-standard kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: fast provisioner: kubernetes.io/gce-pd parameters: type: pd-ssd 绑定 用户创建一个PVC(或者之前就已经就为动态供给创建了),指定要求存储的大小和访问模式。master中有一个控制回路用于监控新的PVC, 查找匹配的PV(如果有),并把PVC和PV绑定在一起。如果一个PV曾经动态供给到了一个新的PVC,那么这个回路会一直绑定这个PV和PVC。另外, 用户总是至少能得到它们所要求的存储,但是volume可能超过它们的请求。一旦绑定了,PVC绑定就是专属的,无论它们的绑定模式是什么。 如果没找到匹配的PV,那么PVC会无限期得处于unbound未绑定状态,一旦PV可用了,PVC就会又变成绑定状态。比如,如果一个供给了很多50G的PV集群,不会匹配要求100G的PVC。直到100G的PV添加到该集群时,PVC才会被绑定。 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-test01 namespace: spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi 使用 Pod使用PVC就像使用volume一样。集群检查PVC,查找绑定的PV,并映射PV给Pod。对于支持多种访问模式的PV,用户可以指定想用的模式。 一旦用户拥有了一个PVC,并且PVC被绑定,那么只要用户还需要,PV就一直属于这个用户。用户调度Pod,通过在Pod的volume块中包含PVC来访问PV。 kind: Pod apiVersion: v1 metadata: name: task-pv-pod spec: volumes: - name: task-pv-storage persistentVolumeClaim: claimName: pvc-test01 containers: - name: task-pv-container image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - mountPath: "/usr/share/nginx/html" name: task-pv-storage 释放 当用户使用PV完毕后,他们可以通过API来删除PVC对象。当PVC被删除后,对应的PV就被认为是已经是“released”了,但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中,必须根据策略来处理掉。 回收 PV的回收策略告诉集群,在PV被释放之后集群应该如何处理该PV。当前,PV可以被Retained(保留)、 Recycled(再利用)或者Deleted(删除)。保留允许手动地再次声明资源。对于支持删除操作的PV卷,删除操作会从Kubernetes中移 除PV对象,还有对应的外部存储(如AWS EBS,GCE PD,Azure Disk,或者Cinder volume)。动态供给的卷总是会被删除。 参考: https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
来源:OSCHINA
发布时间:2018-04-10 11:04:00
1、 shell特殊符号cut命令 *任意个任意字符 # ?任意一个字符 # #注释字符 # \脱义字符 # |管道符号 # 和管道有关的命令 cut的作用截取字符串 cut 分割,-d分隔符 -f指定段号 -c指定第几个字符 sort排序,-n 以数字排序; -r反序 -t分隔符 -kn1/kn1,n2 wc -l 统计行数 -m 统计字符串 -wl 统计词 uniq去重 , -c统计行数 tee和>类似,重定向的同时还在屏幕显示 tr替换字符, tr 'a''b',大小写替换tr '[a-z]''[A-Z]'把所有的小写变成大写的,tr'[a]' '[A]'或者tr 'a' 'A'把小写的a变成大写的A Split切割, -b大小(默认单位字节) ,-l 行数 cut命令的实例:最后一个可以写成1-3 2、 sort_wc_uniq命令 sort实例: 加上-n,按照数字排序大小;sort -nr 1.txt可以反向排序。 使用-m统计字符串的个数 命令wc -w 2.txt统计2.txt文件的词,以空格或空行做标准 uniq去重实例:需要排序,再去重(复的) 使用命令:sort 2.txt |uniq, -c计算重复的次数 把前面的内容输出到后面去,sort 2.txt |uniq -c > a.txt , 清空的命令:>a.txt,把a.txt文件清空。 3、 tee_tr_split命令 tee 比 > 就多了一个立即显示重定向内容的好处 tr替换字符实例:tr 'a''b',大小写替换tr '[a-z]''[A-Z]'把所有的小写变成大写的, Split切割实例: 使用find 命令把所有的后缀为conf文件,追加到a.txt的文件中,使用>>命令,missing argument是遗漏的意思。 添加前缀abc 4、shell特殊符号下 变量前缀,!$组合,正则里面表示行尾 ;多条命令写到一行,用分号分割。 ~用户家目录,后面正则表达式表示匹配符 &放到命令后面,会把命令丢到后台 >:把正确的重定向到一个文件中去; > >:把前面的追加到后面的文件中; 2> :2>> ; &>:把错误的正确的都输出到一个文件中去 []指定字符中一个,[0-9],[a-zA-Z],[abc] ||和&&,用于命令之间;或者的意思 ||:前面的命令执行成功了,后面的就不执行了。 &&:先执行前面的命令再执行后面的命令。 实例: -d指定的目录,不存在就去创建,存在就不执行后面的命令了,就不创建了。
来源:OSCHINA
发布时间:2018-04-10 15:50:00
摘要: 阿里有很多的研发团队,不同事业部使用的发布流程、分支策略并非整齐划一,但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式,称为“AoneFlow”。这套工作模式思路独特,在阿里以外的地方并不多见。本文围绕这些实践,聊一聊分支管理的话题。 引言 在阿里内部,流行着许多有意思的工程实践。有些实践通过工具和流程嵌在集团的大环境里,外界不容易复制,有些实践则是流露在大家的日常习惯里,被默默的遵守。比如分支管理这件事,其实属于工具和习惯各占一半,并且颇有阿里特色的成分,适合作为一个例子。阿里有很多的研发团队,不同事业部使用的发布流程、分支策略并非整齐划一,但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式,称为“AoneFlow”。这套工作模式思路独特,在阿里以外的地方并不多见。本文围绕这些实践,聊一聊分支管理的话题。 细数分支模式 说到分支管理模式,我们最耳熟能详的莫过于 TrunkBased 和 GitFlow。 TrunkBased 模式是持续集成思想所崇尚的工作方式,它由单个主干分支和许多发布分支组成,每个发布分支在特定版本的提交点上从主干创建出来,用来进行上线部署和 Hotfix。在 TrunkBased 模式中,没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支,TrunkBased 也并非排斥短期的特性分支存在,只不过在说这种模式的时候,大家通常都不会明确强调它罢了。 虽然近年来有许多不错的案例,但 TrunkBased 模式并没有一统天下。它的缺点比较明显,太多的团队同时工作在主干上,到发布的时候就可能出现灾难(尤其是多版本并行开发的情况)。弥补的措施是 FeatureToggle 以及频繁的集成和足够的测试覆盖,这对开发团队的能力提出了比较高的要求。目前 TrunkBased 模式主要用在不需要同时维护多个历史版本的 SaaS 型项目,特别是经过微服务改造的各种小型服务上。 TrunkBased 模式有两种常见演进版本。OneFlow 模式参考了 TrunkBased 的许多思想,对操作流程做了更严格的定义,增加了 Hotfix 分支等内容。多主干模式(通常是双主干,固定的开发分支和固定的发布分支),算是 TrunkBased 采用固定发布分支的特例,在提升团队的微服务落地能力这篇文章里介绍过,不再赘述。 GitFlow 模式是若干模式的集大成者,包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支,以及许多繁琐的合并规则。它有一个 Git 插件,不过早就没人维护了。由于对每个阶段的每项操作定义十分明确,它曾经是很多重视流程的企业眼里的香馍馍。但它使用起来并不是很容易,大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。 对,还有 GithubFlow 模式,不过这种策略无非是在 TrunkBased 的基础上,增加了个人仓库和 Pull Request 合并代码的操作,与在同一个仓库里增加个人分支的做法类似,从实用的意义来说,它更合适分布式团队。GithubFlow 也有演进版本,例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。 要么简单粗暴如 TrunkBased,要么繁琐复杂如 GitFlow。难到真没有其他选择了吗? 另辟蹊径的 AoneFlow 在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点,同时规避掉 GitFlow 的那些繁文缛节。 看一下具体套路。AoneFlow 只使用三种分支类型:主干分支、特性分支、发布分支,以及三条基本规则。 规则一,开始工作前,从主干创建特性分支。 AoneFlow 的特性分支基本借鉴 GitFlow,没有什么特别之处。每当开始一件新的工作项(比如新的功能或是待解决的问题)的时候,从代表最新已发布版本的主干上创建一个通常以feature/前缀命名的特性分支,然后在这个分支上提交代码修改。也就是说,每个工作项(可以是一个人完成,或是多个人协作完成)对应一个特性分支,所有的修改都不允许直接提交到主干。 规则二,通过合并特性分支,形成发布分支。 AoneFlow 的发布分支设计十分巧妙,可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线(即开发分支),然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成,然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是,从主干上拉出一条新分支,将所有本次要集成或发布的特性分支依次合并过去,从而得到发布分支。发布分支通常以release/前缀命名。 这条规则很简单,不过实际的玩法就相当丰富了。 首先,发布分支的用途可以很灵活。基础玩法是将每条发布分支与具体的环境相对应,比如release/test分支对应部署测试环境,release/prod分支对应线上正式环境等等,并与流水线工具相结合,串联各个环境上的代码质量扫描和自动化测试关卡,将产出的部署包直接发布到相应环境上。进阶点的玩法是将一个发布分支对应多个环境,比如把灰度发布和正式发布串在一起,中间加上人工验收的步骤。高级的玩法呢,要是按迭代计划来关联特性分支,创建出以迭代演进的固定发布分支,再把一系列环境都串在这个发布分支的流水线上,就有点经典持续集成流水线的味道了。再或者做一个将所有特性分支都关联在一起的发布分支,专门用于对所有提交做集成测试,就玩出了 TrunkBased 的效果。当然,这些花哨的高级玩法是我臆想的,阿里的发布分支一般都还是比较中规中矩。 其次,发布分支的特性组成是动态的,调整起来特别容易。在一些市场瞬息万变的互联网企业,以及采用“敏捷运作”的乙方企业经常会遇到这种情况,已经完成就等待上线的需求,随时可能由于市场策略调整或者甲方的一个临时决定,其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题,需要排除。按往常的做法,这时候就要来手工“剔代码”了,将已经合并到开发分支或者主干分支的相关提交一个个剔除出去,做过的同学都知道很麻烦。在 AoneFlow 的模式下,重建发布分支只是分分钟的事,将原本的发布分支删掉,从主干拉出新的同名发布分支,再把需要保留的各特性分支合并过来就搞定。这一系列动作能够在很大程度上实现自动化,而且不会在仓库留下一堆剔除代码的记录,干净无污染。 此外,发布分支之间是松耦合的,这样就可以有多个集成环境分别进行不同的特性组合的集成测试,也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性,由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的,在流程上可以要求只有通过前一环境验证的特性,才能传递到下一个环境做部署,形成漏斗形的特性发布流。阿里有统一平台来自动化完成特性组合在发布分支间的迁移,在下面讲工具的部分里会再介绍。 规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加标签,同时删除该发布分支关联的特性分支。 当一条发布分支上的流水线完成了一次线上正式环境的部署,就意味着相应的功能真正的发布了,此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支,还应该清理掉已经上线部分特性分支。与 GitFlow 相似,主干分支上的最新版本始终与线上版本一致,如果要回溯历史版本,只需在主干分支上找到相应的版本标签即可。 除了基本规则,还有一些实际操作中不成文的技巧。比如上线后的 Hotfix,正常的处理方法应该是,创建一条新的发布分支,对应线上环境(相当于 Hotfix 分支),同时为这个分支创建临时流水线,以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是,将线上正式环境对应的发布分支上关联的特性分支全部清退掉,在这个发布分支上直接进行修改,改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢?那就老老实实的在主干分支找到版本标签位置,然后从那个位置创建 Hotfix 分支吧,不过由于阿里的产品大多是线上 SaaS 业务,这样的场景并不多见。 正是这些简单的规则,组成了 AoneFlow 独树一帜的核心套路。 AoneFlow 中每一个看似简单的步骤都并非凭空臆造,而是经历大量产品团队反复磨砺后积累下来的经验。接下来,我会说说 AoneFlow 的技术门槛以及阿里内部的应对之道。 AoneFlow 的体验优化 谙熟武侠之道的人都懂得,掌握一个门派的看家武艺,除了要会招式,还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱,也只能望谱兴叹。 阿里团队的内功和兵器,实际上是良好的代码习惯和齐全的配套工具。 这里说的习惯,除了开发流程和代码分支的管理方式以外,还包括日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记载的,主要收录在 《阿里巴巴 Java 开发手册》 里面。它的内容现在已经公开了,所以早就不算是秘密。 举一个具体的例子。在 AoneFlow 的流程中,每次重建发布分支的时候都会重新合并然后编译代码,产生新的部署包。然而,即使代码的内容是一样的,如果工程中依赖了一些会改变的第三方软件包,依然可能导致打包出的产品行为不完全一致。因此,在阿里的代码规约中就明确地指出了,用于线上发布的代码,不可以使用包含“SNAPSHOT 版本”(即未正式发布版本)的依赖包,从而确保每次构建出的产物都是一致的。类似这样的细节还有很多,好的开发习惯是确保软件质量的必要前提。 工具可以使得团队协作更加平滑。虽然只要弄懂原理,AoneFlow 中每个分支创建、合并、更改步骤使用单纯的 Git 命令就能玩转。但其中的一些操作(比如为每个发布分支选出恰当的特性分支组合进行合并)手工执行极易出错,而且让团队的个人重复这些日常琐事的命令操作,并不是令人愉悦的事情。 在阿里内部,使用 AoneFlow 流程的团队基本上不用自己运行 Git 来处理分支的事情,而是由阿里巴巴集团内部名叫 Aone 的协同研发平台(以下简称平台)接管。这个承担集团 80% 产品从需求和用户故事提出到部署上线完整研发流程的平台,内置了许多以服务组件的形式嵌入的研发提效工具,其中的发布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“功效”包括以下几个方面。 首先是整体流程的自动化。 由于是内部工具,平台的功能高度内聚。对于项目而言,从提出原始需求,将需求拆分为任务,然后根据任务在线创建特性分支,再聚合生成发布分支,同时根据模板自动创建测试环境,直到后期的运维保障都可以一站式的搞定。 这个流程已经远远超出了代码分支管理的范畴。但正是因为如此,平台对于 AoneFlow,向前做到了将特性分支和需求项关联起来,确保了特性分支的命名规范性;向后做到了将发布分支与部署行为关联起来,确保了各环境版本来源的可靠性。打通了端到端交付的任督二脉。 其次是发布分支的流水线。 作为一种流程自动化的手段,CI/CD 流水线是许多现代交付团队中常见的标配实践。在 AoneFlow 的代码生命周期里涉及许多分支,当这些分支被创建或更新时,往往需要伴随其他的一系列行为。流水线能够将这些日常开发过程中的代码分支与其所表达的深层意图(比如提交代码即进行集成测试)联系起来。特别是发布分支,AoneFlow 的每个发布分支通常关联具体的部署环境,当有新代码合并进分支时,就应该及时对代码进行检查和部署。 理想情况下,每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。AoneFlow 的发布分支是相对固定的,因此相比 GitFlow 更易于进行持续集成。理论上任何流水线工具都能够配合 AoneFlow 使用,不过,阿里的统一平台提供流水线对代码评审、安全检查、在线部署等功能的整合,还是为 AoneFlow 在内部团队的使用优化增色不少。 还有一项很有用的辅助是分支关联的管理。 特性分支与发布分支的关联关系维护是一个 AoneFlow 特有的问题。记住每个发布分支分别来自哪些特性分支对于需要基于现有特性组合进行改变的时候十分有意义。比如当需要将某个特性从特定发布分支退出时,通常会将除了该特性以外的其他特性所在分支进行一次合并,以替换原有的发布分支。人为的记录这些信息并不轻松,要是通过平台进行展示和辅助就会方便许多。 当某些功能组合在一个低级别的发布环境(如集成测试环境)验证完成后,我们希望将它的内容直接迁移到高级别的环境(如预发布环境)对应的发布分支上。这样可以确保线上的版本一定是经过预发验证的,预发的版本一定是经过集成验证的,以此类推,使得各个发布分支形成串联。同样的,使用普通的 Git 命令就能实现这个操作,只不过用可视化工具会让流程更加直观。 除此以外,平台提供代码仓库各个分支状况的统一展示,包括分支所对应部署环境的机器信息、操作记录等全都一览无余。正是这些“高附加值”的辅助,使得 AoneFlow 得以扬长避短,成为阿里团队支撑复杂项目首选的利器。 写在最后 代码分支模式的选择并没有绝对的正确和错误之分,关键是与项目的规模和发布节奏相匹配。阿里协同研发平台在经过众多实践历练后,总结出了一套独创的分支管理方法,通过兼备灵活高效与简单实用的流程,保障阿里旗下众多产品的交付。当你还在犹豫于琳琅满目的分支模式,既舍不得 GitFlow 的并行特性开发,又放不下 TrunkBased 的持续集成友好时,AoneFlow 也许是一个值得考虑的选择。 原文链接
来源:OSCHINA
发布时间:2018-04-10 10:49:00
万恶的GWF导致通过官方安装地址安装minikube问题多多,阿里云社区提供了科学版的minikube,感谢阿里云! 安装hyperkit虚拟机: curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \ && chmod +x docker-machine-driver-hyperkit \ && sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \ && sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \ && sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit 安装minikube: curl -Lo minikube http://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v0.25.2/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/ 安装kubectl: curl -Lo kubectl http://storage.googleapis.com/kubernetes-release/release/v1.10.0/bin/darwin/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/ && chmod +x kubectl && sudo mv kubectl /usr/local/bin/ 启动minikube: minikube start --vm-driver hyperkit or minikube start --vm-driver hyperkit --registry-mirror=https://registry.docker-cn.com 切换到minikube VM的docker eval $(minikube docker-env) 运行dashboard: minikube dashboard
来源:OSCHINA
发布时间:2018-04-09 21:31:00
Rancher 2.0 Beta现已正式发布!这是在4月底Rancher 2.0 GA之前最重要的里程碑发布,Rancher 2.0主分支现已包含所有关键功能,Rancher Labs团队即将进入最终Beta阶段,将工作焦点放在测试、文档和扩展性上。 自2017年9月Rancher 2.0技术预览版I发布以来,Rancher Labs研发团队持续进行着Rancher 2.0的功能开发和代码重构工作,先后继续发布了Rancher 2.0技术预览版II和III,且收到了来自客户及开源社区的极为积极的反馈。历时一年的Rancher 2.0开发工作正式进入最终阶段,Rancher 2.0 Beta是Rancher 2.0中最后一个主要的功能集。 Rancher 2.0是一个企业级Kubernetes平台,能够让你统一管理所有云上的所有Kubernetes发行版以及所有的Kubernetes集群。Rancher 2.0由3个主要组件构成:Rancher Kubernetes引擎(RKE)、统一集群管理(Unitied Cluster Management)和工作负载管理(Workload Management)。 Rancher Kubernetes引擎(RKE) 1. 轻量级的Kubernetes安装程序 为方便希望在vSphere集群、裸机服务器以及不支持托管Kubernetes的云提供商上部署Kubernetes的用户,Rancher 2.0中嵌入了RKE。 **2. 简单的Kubernetes操作 ** Rancher支持Kubernetes集群的持续操作,例如集群升级和etcd备份。 3. 驱动Rancher服务器高可用 Rancher可以安装到现有的Kubernetes集群中,该集群可以是为了运行Rancher服务器而创建的小型RKE集群。 统一集群管理 1. 集群和节点管理 不论是由云提供商(谷歌GKE、微软AKS、亚马逊EKS、华为云、阿里云等)托管的Kubernetes集群,还是使用RKE新创建的Kubernetes集群,抑或是从他处导入的现有Kubernetes集群,Rancher 2.0平台均可支持集群和节点的统一管理。 2. 认证 Rancher支持本地认证、Github,以及针对所有GKE、AKS、EKS、RKS、导入集群的AD/LDAP认证。 3. 用户管理 Rancher支持两种默认的用户类型,admin和user,并且可以定义自定义用户类型。 4. 基于角色的访问控制 (Role Based Access Control,RBAC)。Rancher用户可以创建自己的全局集群角色,它可以轻松地分配工作给任何用户,从而管理Kubernetes集群和项目。Rancher包含所有开箱即用的Kubernetes角色,并且还可自定义自己的角色。每个角色都可以分配到全局、集群或者项目层面。 5. 项目和命名空间管理 用户可以创建命名空间并将其分配给项目。“项目”是一种新的Rancher概念,它可以让你对一组命名空间进行分组,并为这些命名空间分配用户权限。 6. Pod安全策略 Rancher 2.0可以让用户创建他们自己的pod安全策略,也可以创建应用于角色的安全策略。 7. Rancher CLI CLI支持所有主要的Rancher 2.0功能集。 工作负载管理 1. 工作负载UI Rancher推出了新的工作负载UI,用户可以利用它简单地创建和管理他们的Kubernetes工作负载。 2. Helm目录支持 Rancher 2.0的Catalog(应用程序目录)是建立在Helm charts上的。 3. 告警管理 Rancher 2.0利用Prometheus AlertManager向各种通知器(包括Slack、Email、PagerDuty和Webhooks)发送系统和用户级的告警。 4. 日志管理 Rancher 2.0中安装了Fluentd,来收集写入特定目录的stdout/err输出或日志。Rancher 2.0支持各种日志目标,包括ElasticSearch、Splunk、Syslog和Kafka。 5. CI/CD Pipeline Rancher 2.0包含一个简单的集成pipeline功能,用户可在项目中创建pipeline来实现持续集成。 从Rancher 1.6迁移到Rancher 2.0 我们最初计划在Rancher 2.0中同时支持Rancher Compose文件和Kubernetes YAML模板。这样一来从Rancher 1.6迁移到Rancher 2.0就会非常简单:你可以将现有的compose文件replay在Rancher 2.0上。 然而不幸的是,我们尝试在Kubernetes上实现完全兼容的Rancher Compose体验时,遇到了巨大的技术挑战。Kubernetes支持许多类似于Cattle的概念。然而,两者之间仍经常存在着重要的差异,这使得转换工作变得非常困难。早期版本的Rancher 2.0 技术预览版I将Rancher Compose结构转换成Pod,绕过了Kubernetes编排。但是根据用户的反馈来看,这并不是最正确的解决方案。相反,我们发现有相当数量的Cattle社区用户对Kubernetes的功能非常感兴趣,而且由于Cattle和Kubernetes之间的相似性,从Rancher Compose创建Kubernetes YAML文件并不太难。 因此,我们决定专注于在Rancher 2.0中单独支持Kubernetes YAML模板,并且开发工具和实践来帮助Cattle用户在Rancher 2.0到Rancher 2.1的这一时间段内迁移到Kubernetes。当然,Rancher Labs会继续提供Rancher 1.6至少一年的支持。随着新兴容器行业的发展,我们也会持续关注Cattle用户社区的需求。 整个Rancher 2.0项目的打造过程之中,我们肩负了将Rancher从基于Docker改变为基于Kubernetes的艰巨任务。我们用Go语言重写了所有遗留的Rancher 1.6 Java模块,在此过程中还涉及到了系统中的几乎所有其他模块。Rancher Labs的数十名核心开发人员同时投入到这一项目中。事实上,这么多开发人员能够如此迅速地进行协作和行动,也是Kubernetes平台的模块化和成熟的证明。我们也更加确信,Kubernetes会成为企业应用程序的基础平台。 结语 Rancher 2.0简洁直观的界面风格及操作体验,将解决业界遗留已久的Kubernetes原生UI易用性不佳以及学习曲线陡峭的问题。而Rancher 2.0创造性的多Kubernetes集群管理功能,更是将解决生产环境中企业用户可能面临的基础设施不同的困境。加之Rancher 2.0带来的监控、日志、CI/CD等一系列拓展功能,可以说,Rancher 2.0为企业在生产环境中落地Kubernetes提供了更加便捷的途径。 秉承Rancher一贯100%开源的风格及理念,你可以直接从GitHub上下载体验Rancher 2.0最新版本: https://github.com/rancher/rancher/releases Rancher微信公众号(RancherLabs)后台回复“架构”,可下载Rancher 2.0的架构文档! 想要观看Rancher 2.0的演示、了解更多Rancher 2.0的实际应用?欢迎加入4月19日晚的在线培训:使用Rancher 2.0管理Kubernetes集群
来源:OSCHINA
发布时间:2018-04-09 20:13:00
大约 8个月前, CNCF 的技术监督委员会 (TOC) 开始着手探究相对较新的 “无服务器计算”世界。 他们想知道: 行业内无服务器领域的发展现状, 以及是否应该在这个领域做些什么 来帮助社区。 为此,他们决定成立一个新工作组来做这项调查。调查涉及了以下主题: 无服务器计算是什么? 它与功能即服务以及其他 *aaS 云计算模型有何关系?何时应考虑使用无服务器计算?社区中无服务器计算的现状 – 例如,您在运行时、框架等方面使用哪些选项? 无服务器处理模型。这里主要围绕大多数无服务器平台中常见的架构进行讨论,而不关注任何特定的实施选择。主要面向那些想要了解它背后工作方式的人。 CNCF 建议。工作组拟定了 TOC 可能要考虑的后续步骤的清单。大多数都涉及到“社区建设”。 工作组认为,要想在这样一个崭新的空间迅速获得互通性案例可能会遭遇重重阻力,但是,通过选择关注现有供应商中看起来存在某种一致性的领域,我们就可能会循序渐进地朝着正确的方向迈进。 若取得成功,它将使用户的生活变得更轻松。 因此,无服务器工作组目前正围绕着定义通用事件格式制定全新的 CloudEvents 规范。 虽然此规范出自“无服务器”工作组之手,但人们已经认识到这种事件格式可以应用于任何事件,而不管处理事件的基础架构如何。 即刻点击“ 阅读原文 ”获得完整文章,让我们一起揭开无服务器计算新篇章!
来源:OSCHINA
发布时间:2018-04-09 15:27:00
处理数据的机制称为管道。 在配置级别上,管道描述数据来源和相应的汇合点之间的耦合,用于转换和公布数据。 此功能由通知代理处理。 source是数据的生产者: samples 或 events 。 实际上, 它是一组为匹配的 meters和事件类型集合 发出数据点的通知处理程序。 每个source配置将名称匹配和映射封装到一个或多个 sinks 中以供发布。 另一方面,sink是数据的使用者,为转换和发布来自相关源的数据提供逻辑。 实际上,sink描述了一系列的处理程序。 该 chain 从零或更多的 transformers 开始,并以一个或多个 publishers 结束。 chain中的第一个transformer从对应的source传递数据, 采取一些操作, 例如 deriving变动率, 执行单位转换或聚合, 然后 publishing 。 管道配置 通知代理支持两种管道: 一个处理 samples,另一个处理events。 通过在[notifications]设置管道选项,可以启用和禁用管道。 默认情况下,每个管道的实际配置存储在单独的配置文件中: pipeline.yaml 和 event_pipeline.yaml 。配置文件的位置可以由 pipeline_cfg_file 和 event_pipeline_cfg_file 选项设置,配置文件模板查看: Ceilometer Configuration Options 。 meter pipeline 的定义如下的: --- sources: - name: 'source name' meters: - 'meter filter' sinks: - 'sink name' sinks: - name: 'sink name' transformers: 'definition of transformers' publishers: - 'list of publishers' 有几种方法可以定义管道源的meters列表。 有效计量表的清单可以在 Measurements 中找到。 有种方式可以定义所有的 meters 或者只包含或过滤部分 meters,一个 source 配置操作应该按下面方式: 包含所有的 meters 使用*号通配符。但明智的做法是只选择您打算使用的meters,以避免使用了未使用过的数据淹没了计量数据库。 要定义meters列表,可使用下列任何一种: 要包含部分meters,可使用 meter_name 语法。 要过滤部分meters,可使用 !meter_name 语法。 备注: OpenStack遥测服务在管道之间没有任何重复检查, 如果您在多个管道中添加了一个 meter,则假定重复是有意的,并且可以根据指定的接收器多次存储。 上述定义方法可用于以下组合: 只使用通配符符号。 使用 included meters。 使用 excluded meters。 通配符与 excluded 结合使用。 备注: 以上变化中至少有一种应该被包括在meters section。 Included 和excluded meters不能共存于同一管道中。 通配符和included meters 不能在同一管道定义部分中共存。 管道sink的 transformers部分提供了添加 transformers定义列表的可能性。 现有的transformers: Transformer 的名字 配置的引用名称 Accumulator accumulator Aggregator aggregator Arithmetic arithmetic Rate of change rate_of_change Unit conversion Delta unit_conversion delta 发布者部分包含发布者列表,其中样本数据应该在可能的转换之后发送。 类似地,事件管道定义看起来像下面这样: --- sources: - name: 'source name' events: - 'event filter' sinks: - 'sink name' sinks: - name: 'sink name' publishers: - 'list of publishers' 事件过滤器使用与meter管道相同的过滤逻辑。 Transformers 备注:Transformers在内存中保存数据,因此不能保证在某些场景下的持久性。 使用像Gnocchi这样的解决方案可以实现更持久、更有效的解决方案。 转换器的定义可以包含以下字段: name 转换器的名称 parameters 转换器的参数 参数部分可以包含transformer特定字段, 在变化速率的案例中,像source和target字段包含有不同的子字段,这依赖于 transformer 的实现。 下面是支持的 transformers: Rate of change transformer 此种转换器是计算两个数据点之间的时间变化值。下面的transformer例子定义了 cpu_util meter: transformers: - name: "rate_of_change" parameters: target: name: "cpu_util" unit: "%" type: "gauge" scale: "100.0 / (10**9 * (resource_metadata.cpu_number or 1))" 变化率的transformer从cpu计数器的样本值生成 cpu_util meter, 它代表了纳秒的累计CPU时间。 上面的transformer定义定义了一个比例因子(用于纳秒和多cpu), 在转换之前应用于从cpu表的顺序值派生出一个带有%单位的度量样本序列。 磁盘I/O速率的定义,也由变化率的转换器生成 : transformers: - name: "rate_of_change" parameters: source: map_from: name: "disk\\.(read|write)\\.(bytes|requests)" unit: "(B|request)" target: map_to: name: "disk.\\1.\\2.rate" unit: "\\1/s" type: "gauge" Unit conversion transformer 此种转换器应用于单位转换。 它接收meter的volume,并将它乘以给定的尺度表达式。 也支持如 transformer变化率一样带有 map_from 和 map_to 字段。 样本配置: transformers: - name: "unit_conversion" parameters: target: name: "disk.kilobytes" unit: "KB" scale: "volume * 1.0 / 1024.0" 使用 map_from 和 map_to : transformers: - name: "unit_conversion" parameters: source: map_from: name: "disk\\.(read|write)\\.bytes" target: map_to: name: "disk.\\1.kilobytes" scale: "volume * 1.0 / 1024.0" unit: "KB" Aggregator transformer 在到达足够的样本或超时之前, 此种转换器会对输入的样本进行汇总。 可以使用 retention_time 选项指定超时。 如果您想要刷新aggregation,在聚合了一定数量的samples之后,请指定参数大小。 所创建的样本容量是输入到l转换器的样本容量的总和。 样本可以通过 project_id , user_id 和 resource_metadata 属性聚合。 根据所选择的属性进行聚合,在配置中指定它们,并设置该属性的值以获取新样本( 首先使用第一个样本属性,最后取最后一个样本属性,然后删除该属性)。 通过 resource_metadata 汇总60秒的样本值,并保存最新收到的样本的 resource_metadata : transformers: - name: "aggregator" parameters: retention_time: 60 resource_metadata: last 通过 user_id 和 resource_metadata 聚合每个15个样本, 并保留第一个接收到的sample的 user_id ,并删除 resource_metadata : transformers: - name: "aggregator" parameters: size: 15 user_id: first resource_metadata: drop Accumulator transformer 这种转换器只是简单地缓存样本,直到达到足够的样本,然后立即将它们全部冲下管道: transformers: - name: "accumulator" parameters: size: 15 Multi meter arithmetic transformer 此种转换器使我们能够在一个或多个meters上进行算术运算,进行 and/or元数据。例如: memory_util = 100 * memory.usage / memory 根据 transformer 配置的 target 部分里的属性描述会创建一个新的sample。 样本容量是根据提供的表达式计算的结果。 对同一资源的样本进行计算。 备注: 计算的范围仅限于同一区间内的 meter。 例子配置文件: transformers: - name: "arithmetic" parameters: target: name: "memory_util" unit: "%" type: "gauge" expr: "100 * $(memory.usage) / $(memory)" 为了演示元数据的使用,以下一种新型测量器的实现显示了每个核心的平均CPU时间: transformers: - name: "arithmetic" parameters: target: name: "avg_cpu_per_core" unit: "ns" type: "cumulative" expr: "$(cpu) / ($(cpu).resource_metadata.cpu_number or 1)" 备注: Expression evaluation gracefully handles NaNs and exceptions. 在这种情况下,它不会创建一个新的sample,而是只记录一个警告。 Delta transformer 这种转换器计算一个资源的两个样本数据点之间的变化。 它可以配置为只捕获正增长的增量(deltas)。 实例配置: transformers: - name: "delta" parameters: target: name: "cpu.delta" growth_only: True Publishers 遥测服务提供几种传输方法,将收集到的数据传输到外部系统。 这些数据的消费者有很大的不同,就像监视系统一样,数据丢失是可以接受的但计费系统需要可靠的数据传输。遥测技术提供了满足两种系统要求的方法。 发布者组件可以通过消息总线将数据保存到持久存储中,或将其发送给一个或多个外部消费者。一个chain可以包含多个发布者。 为了解决这个问题,可以为遥测服务中的每个数据点配置多发布者,允许将相同的技术meter或事件多次发布到多个目的地,每个目的地都可能使用不同的传输。 支持下面的发布者类型: gnocchi (默认) 在启用gnocchi发布者时,会将度量和资源信息推送到gnocchi进行时间序列优化存储。 Gnocchi必须在 Identity服务中注册,因为Ceilometer通过Identity服务来发现确切的路径。 关于如何启用和配置gnocchi的更多细节可以在其 官方文档页面 找到。 panko 云计算中的事件数据可以存储在panko中,它提供了一个HTTP REST接口来查询OpenStack中的系统事件。 把数据推给panko, 设置 publisher 为 panko:// 。 notifier notifier publisher 可以以 notifier://?option1=value1&option2=value2 的形式指定。 它使用oslo.messaging来发出AMQP的数据。 然后,任何消费者都可以订阅已发布的主题进行额外的处理。 以下是可用的定制选项: per_meter_topic 这个参数的值是1。 它用于在额外的 metering_topic.sample_name 主题队列,除了默认的 metering_topic 队列,发布samples。 policy 用于配置案例的行为,当发布者无法发送样品时,可能的预定义值是: default : 用于等待和阻塞,直到samples被发送。 drop: 用于丢弃未能发送的samples。 queue: 用于创建内存中的队列,并在下一次样本发布期间重新尝试将样品发送到队列中(队列长度可以用 max_queue_length 属性来配置,默认值是 1024 )。 topic 要发布到的队列的主题名称。 设置这个选项将会覆盖由 metering_topic 和 event_topic 默认设定的主题。 这个选项可以用来支持多个消费者。 udp 此publisher 可以用 udp://:/ 的形式指定。 它通过UDP发出计量数据。 file 此publisher 可以用 file://path?option1=value1&option2=value2 的形式指定。 此种发布者将测量数据记录到一个文件中。 备注: 如果没有指定文件名和位置, file 发布者不会记录任何meters,而是为Telemetry在配置的日志文件中记录一条警告消息。 以下选项可供 file publisher 使用: max_bytes 当这个选项大于零时,它将导致翻转。 当指定的大小即将溢出时,文件将被关闭,一个新的文件将被静默打开以输出。 如果它的值为零,那么翻转就不会发生。 backup_count 如果该值是非零的,则扩展将被追加到旧日志的文件名,如.1、.2等等,直到达到指定的值为止。 编写状态和包含最新数据的文件始终是没有任何指定扩展的。 http 遥测服务支持将samples发送到外部HTTP目标。samples没有任何修改地发出。 要将此选项设置为通知代理目标,请将 http:// 设置为管道定义文件中的发布者端点。 HTTP目标应该与发布者声明一起设置。 例如,可以通过 http://localhost:80/?option1=value1&option2=value2 来传递额外的配置选项。 下面的选项是可用的: timeout HTTP请求超时前的秒数。 max_retries 在失败之前重试请求的次数。 batch 如果为 false, 发布者将分别发送每个sample和event,无论通知代理是否被配置成批量处理。 verify_ssl 如果为 false,则禁用ssl证书验证。 默认发布者是gnocchi,没有指定其他选项。 /etc/ceilometer/pipeline.yaml 配置文件里的 sample publisher部分类似下面: publishers: - gnocchi:// - panko:// - udp://10.0.0.2:1234 - notifier://?policy=drop&max_queue_length=512&topic=custom_target 管道分割 备注: Partitioning只有当管道包含有transformations时才是必须的。在某些publishers的支持下, 它有次要的好处。 在大的工作负载下,可以部署多个通知代理来处理来自监视服务的传入消息的泛滥。 如果在管道中启用了转换,则必须协调通知代理,以确保将相关消息路由到同一代理。 要启用协调,请在 notification 部分设置 workload_partitioning 值。 要跨代理分发消息,应该设置 pipeline_processing_queues 选项。 这个值定义了要创建多少个管道队列,然后将其分发给活动的通知代理。 建议处理队列的数量至少与代理的数量匹配。 增加处理队列的数量将改进消息在代理之间的分布。 它还有助于将请求最小化到Gnocchi存储后端。 它还将增加对消息队列的加载,因为它将使用队列到碎片数据。 警告: 减少处理队列的数量可能会导致数据丢失,因为以前创建的队列可能不再被分配给活动代理。 只建议您增加处理队列。 转载: http://luozn.top/2018/04/11/223/
来源:OSCHINA
发布时间:2018-04-09 11:51:00
yum源概述   yum需要一个yum库,也就是yum源。默认情况下,CentOS就有一个yum源。在/etc/yum.repos.d/目录下有一些默认的配置文件(可以将这些文件移到/opt下,或者直接在yum.repos.d/下重命名)。   首先要找一个yum库(源),然后确保本地有一个客户端(yum这个命令就是客户端),由yum程序去连接服务器。连接的方式是由配置文件决定的。通过编辑/etc/yum.repos.d/CentOS-Base.repo文件,可以修改设置。 打开CentOS-Base.repo文件,可以看到url路径是CentOS的官网自身的yum源, http://mirrorlist.centos.org/?release=releasever&arch=releasever&arch=basearch&repo=os 。可以将这个mirrorlist注释掉,然后将baseurl设置成国内的阿里云源 http://mirrors.aliyun.com/repo/Centos-6.repo ,也可以在用于大量的rpm包的前提下设置成自己的本地文件系统(挂载目录),需要移除CentOS-Base.repo文件,并编辑CentOS-Media.repo文件。 name=Description#一个描述,随意。 baseurl=#设置资源库的地址,可以写阿里云也可以是自己的yum ftp:// http:// file:/// enabled={1|0}#enabled=1开启本地更新模式 gpgcheck={1|0}# gpgcheck=1表示检查;可以不检查gpgcheck=0 gpgkey=#检查的key;如果上面不检查这一行可以不写。 [centos] yum软件仓库唯一标识符,避免与其他仓库冲突 name=centos yum软件仓库的名称描述,易于识别仓库用处 baseurl=file:///mnt 提供的方式包括FTP(ftp://..)、HTTP(http://...)、本地(file:///...)。 gpgcheck=0 设置此源是否校验证文件;1为校验,0为不校验。 enabled 设置此源是否可用;1为可用,0为禁用。 centos 多个yum源,系统怎么选择 yum配置文件: /etc/yum.conf pkgpolicy:包的策略。一共有两个选项,newest和last,这个作用是如果你设置了多个repository,而同一软件在不同的repository中同时存在,yum应该安装哪一个,如果是newest,则yum会安装最新的那个版本。如果是last,则yum会将服务器id以字母表排序,并选择最后的那个服务器上的软件安装。一般都是选newest。 如果包在两个yum源中都有,会在下面的文件中按顺序: /var/cache/yum/x86_64/6/timedhosts.txt yum源配置的两种方法 : 配置方法一 : (本地挂载目录) 本地挂载 配置方法二(远程挂载目录) 网络挂载 (常见的 阿里云源 ) 1、 yum更换国内源 cd /etc/yum.repos.d/ #切换到/etc/yum.repos.d/ rm -f dvd.repos #删除dvd.repos wget http://mirrors.163.com/.help/CentOS7-Base-163.repo 或者 curl -O http://mirrors.163.com/.helpo/CentOS7-Base-163.repo # yum list #安装CentOS7-Base-163.repo的源 实例: 使用cp ../yum.repos.d.bak/* . ,把之前的拷贝回来,CentOS-Base.repo是yum源。 安装下载国内源 使用vim查看安装的源,使用yum list 查看 安装zlib yum安装失败,重新生成缓存,执行完图形中的命令后,使用yum clean all 和yum install zsh命令。 清理所有的缓存。 查看有哪些仓库 下载wget 常见问题:报错的原因,可能是因为没有把dev.repo删除 2、 yum下载rpm包 yum install -y 包名 --downloaonly    #仅仅下载不安装 ls /var/cache/yum/x86-64/7/        #查看下载的位置 yum list -y 包名 --downloaonly --downloaddir=路径 # yum reinstall -y 包名 --downloaonly --downloaddir=路径  #重新安装到指定下载的目录 先使用yum list查看有没有安装,然后使用yum install安装。 指定下载的rpm包 指定下载的目录为/tmp/,使用ls /tmp/查看下。 注意:你如果用的是本地的yum源的话,它确实不支持下载。要用网络的源才行。 3、源码包安装 安装扩展源epel yum install -y epel-release #安装源epel-release,安装完成后,使用yum list 查看下 yum list |grep epel #查看源epel 源码包安装 1.cd /usr/local/src/ #切换到/usr/local/src/目录,把源码包放在/usr/local/src/目录下 2.wget http://mirrors.cnnic.cn/apache/httpd/httpd-2.2.32.tar.gz #下载压缩包 3.tar zxvf httpd-2.2.32.tar.gz #解压缩httpd-2.2.32.tar.gz 4.cd httpd-2.2.32 #切换到httpd-2.2.32 然后使用ls命令下有一个叫INSTALL的文件,使用more INSTALL查看 5、 (1) ./configure --prefix=/usr/local/apache2 #指定安装路径 (2)make # (3)make install # 卸载就是删除安装的文件 源码包下载地址:r.aminglinux.com 下载 httpd-2.2.32.tar.gz 包, 5、 ./configure --prefix=/usr/local/apache2 #指定安装路径 如果后面结果是No,说明没有安装。使用命令 解决办法:你下载一个包,编译安装:yum -y install pcre-devel ,,只是编译,,接着make,,make && make install 安装apr-util报的错。 安装一个依赖包就好了 ,命令: yum install expat-devel 编译成功 再安装应该没多大问题 这是编译的显示(参数),接着make&&make install 安装完成了 apr \apr-util编译的两个版本:1、./configure --prefix=/usr/local/apache --with-included-apr 2、./configure --prefix=/usr/local/apache2 --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util 如果还是不行,把你下载的apr和apr-util源码包解压到httpd下面的srclib目录里面,重命名为apr和apr-util,,,解压apr和apr-util包到这个目录下 查找资料包里面的httpd目录下的srclib目录,,重新编译,要在源码包里面。 Make提示错误。是依赖的目录不对。 安装的目录,解压到当前的目录下。安装就指定目录了。Src目录 编译的时候禁用 proxy 就可以了 ,命令: ./configure --prefix=/usr/local/apache2 --disable-proxy 安装2.4.33的httpd安装不了,试着安装2.4.29的httpd httpd 2.4.33版本报错,编译安装完apr和apr-util之后,在编译的时候指定路径也可以解决。 # ./configure --prefix=/usr/local/apache4 --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr 语法错误。使用vi编辑查看,第三十行。 解决办法/原因:版本底,改用python或者把yum的首行该成/usr/bin/python2 还是语法错误。 修复CentOS7升级Python到3.6版本后yum不能正确使用的解决方法 http://www.jb51.net/article/133730.htm?utm_source=debugrun&utm_medium=referral 显示404,,,写错地址了。 使用命令echo $?查看是上一个命令是否错误。如果结果非零,那么就是错的。 使用yum install gcc安装没有安装的包,再运行命令 ./configure --prefix=/usr/local/apache2 查看 再使用命令echo $?查看上一个命令是否正确。 (2).执行make命令 再使用echo $?命令检测下,结果为0,说明没错。 (3). make install 把编译完成的二进制文件目录放到指定的files目录下,在使用下echo $?命令检测下 使用命令ls /usr/local/apache2/查看下 常见问题,执行yum install glibc-static命令。 安装参考链接:http://blog.51cto.com/13658403/2105586 另一个版本的说明:http://blog.51cto.com/11751505/2105637 HOSTORY命令:http://blog.lishiming.net/?p=484 资源链接 : yum源配置的三种方法 : https://www.cnblogs.com/yangp/p/8506264.html 企业实际应用之同步远程yum源到本地 荐 : http://blog.51cto.com/dl528888/1342653
来源:OSCHINA
发布时间:2018-04-09 11:36:00
当 PV 不再需要时,可通过删除 PVC 回收。 当 PVC mypvc1 被删除后,我们发现 Kubernetes 启动了一个新 Pod recycler-for-mypv1 ,这个 Pod 的作用就是清除 PV mypv1 的数据。此时 mypv1 的状态为 Released ,表示已经解除了与 mypvc1 的 Bound,正在清除数据,不过此时还不可用。 当数据清除完毕, mypv1 的状态重新变为 Available ,此时则可以被新的 PVC 申请。 /nfsdata/pv1 中的 hello 文件已经被删除了。 因为 PV 的回收策略设置为 Recycle ,所以数据会被清除,但这可能不是我们想要的结果。如果我们希望保留数据,可以将策略设置为 Retain 。 通过 kubectl apply 更新 PV: 回收策略已经变为 Retain ,通过下面步骤验证其效果: ① 重新创建 mypvc1 。 ② 在 mypv1 中创建文件 hello 。 ③ mypv1 状态变为 Released 。 ④ Kubernetes 并没有启动 Pod recycler-for-mypv1 。 ⑤ PV 中的数据被完整保留。 虽然 mypv1 中的数据得到了保留,但其 PV 状态会一直处于 Released ,不能被其他 PVC 申请。为了重新使用存储资源,可以删除并重新创建 mypv1 。删除操作只是删除了 PV 对象,存储空间中的数据并不会被删除。 新建的 mypv1 状态为 Available ,已经可以被 PVC 申请。 PV 还支持 Delete 的回收策略,会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete ,支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。 下一节我们学习 PV 的动态供给功能。 书籍: 1.《每天5分钟玩转Kubernetes》 https://item.jd.com/26225745440.html 2.《每天5分钟玩转Docker容器技术》 https://item.jd.com/16936307278.html 3.《每天5分钟玩转OpenStack》 https://item.jd.com/12086376.html
来源:OSCHINA
发布时间:2018-04-09 06:16:00
CDN是将源站内容分发至全国所有的节点,从而缩短用户查看对象的延迟,提高用户访问网站的响应速度与网站的可用性的技术。它能够有效解决网络带宽小、用户访问量大、网点分布不均等问题。 为了让大家更全面的了解CDN的原理、调度、缓存和安全等关键技术点,阿里云高级技术专家白金将自己从事 CDN 相关领域工作 8 年来的一些经验、收获和个人认知撰写成《CDN之我见》系列文章,分享给大家。 《CDN 之我见》共分成多个部分,分为原理篇、详解篇和陨坑篇,因为篇幅问题这里先讲第一部分。本篇章适合那些从未接触过、或仅了解一些 CDN 专业术语,想深入了解和感受 CDN 究竟是什么的同学。下面我们进入分享正文: 这个篇章,主要分成 4 个小部分来和大家做一下简单的介绍和分享。 CDN的起源 CDN 诞生于二十多年前,随着骨干网压力的逐渐增大,以及长传需求的逐渐增多,使得骨干网的压力越来越大,长传效果越来越差。于是在 1995 年,MIT 的应用数学教授 Tom Leighton 带领着研究生 Danny Lewin 和其他几位顶级研究人员一起尝试用数学问题解决网络拥堵问题。 他们使用数学算法,处理内容的动态路由安排,并最终解决了困扰 Internet 使用者的难题。后来,史隆管理学院的 MBA 学生 Jonathan Seelig 加入了 Leighton 的队伍中,从那以后他们开始实施自己的商业计划,最终于 1998 年 8 月 20 日正式成立公司,命名为 Akamai。 同年 1998 年,中国第一家 CDN 公司 ChinaCache 成立。 在接下来的20年中,CDN行业历经变革和持续发展,行业也涌现出很多云CDN厂商。阿里云CDN是2008年从淘宝CDN起家,在2014年正式发展成为阿里云CDN的,它不仅为阿里巴巴集团所有子公司提供服务,同时也将自身的资源、技术以云计算的方式输出。 那什么是 CDN 呢? CDN 其实是 Content Delivery Network 的缩写,即“内容分发网络”。 上图是一个做过 CDN 之后的拓扑图,里面有几个概念需要明确一下: Origin Server:源站,也就是做 CDN 之前的客户真正的服务器。 User:访问者,也就是问网站的网民。 Edge Server:CDN 的服务器,不单指“边缘服务器”,这个之后细说。 在 CDN 中,还有 3 个”一英里“的概念,即 First Mile、Middle Mile 和 Last Mile。 First Mile:和 CDN 客户的服务器越近越好的 CDN 设备,即第一英里。 Last Mile:访问者(网民)到离他最近的 CDN 服务器,即最后一英里。 Middle Mile:数据从进入 CDN 网络,到出 CDN 网络之前的所有环节,即中间一英里。 为什么要用 CDN 呢? 从上图可以看到,左图是未做 CDN 之前跨洋跨国的长传业务,用户从西班牙访问到美国纽约要经过北大西洋,直线距离6,000km 左右,按照光速300,000km/s 的传输速度,一束光从西班牙到纽约也至少需要 20ms 时间,一个往返就需要 40ms。如果是光纤传输数据,加上传输损耗、传输设备延时引入等,可能上百毫秒就出去了,即使用浏览器访问一个再小不过的图片,也会等个上百毫秒,积少成多,访问一个美国购物网站会让用户无法接受。 右侧这张图是做过 CDN 之后的示意图。从图上可以看出,网民实际访问到的服务器不是位于美国的真实服务器,而是位于英国的 CDN 服务器。而 CDN 本身有缓存功能,把那些网页里一成不变的内容,例如图片、音乐、视频等,都分发并缓存到了各个 CDN 服务节点上,这样网民就不必从西班牙访问到纽约,而是访问距离自己较近的英国节点即可,从而节省了 80% 以上的时间。 当然,这是一个西班牙访问英国 CDN 节点的例子,如果 CDN 节点也位于西班牙本地,则效果会更加明显,具体细节后续会有更详细的说明。 接下来说一下调度。调度是 CDN 中的重中之重,流量接入、流量牵引、选择合适的 CDN 节点服务器等工作,都是在调度环节完成的。 要理解调度策略和原理,必须先了解 DNS 协议及其工作原理。 我们平时所工作的电脑里,都会配置(人为或自动)一个 DNS 服务器地址,我们称之为”本地 DNS“,也叫 Local DNS,简称 LDNS。在解析一个域名的时候,实际访问的不是”域名“而是 IP 地址,则 LDNS 服务器的用途就是负责将域名翻译成 Internet 可以识别的 IP 地址。 在请求某个域名时,LDNS 一般有两个情况:一种是域名在 LDNS 上有记录,另一种情况是没有记录,两种情况的处理流程不一样。 假设当访问 163 这个域名时,如果 LDNS 上有缓存记录,那它会直接将 IP 地址吐出来。 如果没有缓存记录,它将会一步步向后面的服务器做请求,然后将所有数据进行汇总后交给最终的客户,这个环节术语叫”递归“。 在完全不命中情况,LDNS 首先会向全球13个根域服务器发起请求,询问 .com 域名在哪里,然后根域服务器作出回答,然后去向 .com 的服务器询问 .163.com 在哪里,一步步往下,最后拿到 www.163.com 这个域名所对应的 IP 地址。这个过程较复杂,如果大家感兴趣可去查相关资料,在这就不一一赘述。 肯定很多人好奇是如何进行调度和进行定位的?其实也是通过 LDNS 的具体地址来进行的,如上图所示。 假设网民是一个北京客户,那他所使用的 DNS 服务器去做递归的时会访问到CDN厂商的 GLB(Global Load Balance),它可以看到所访问的域名请求是来自于哪个 LDNS,根据一般人的使用习惯,网民所在位置和 LDNS 所在位置是一样的,因此 GLB 可以间接知道网民来自什么位置。 假如网民是一个北京联通的用户,它使用的 LDNS 地址也是北京联通的,而 LDNS 访问 GLB 也是北京联通的,则 GLB 则认为网民的位置在北京联通,那么会分配一个北京联通的 CDN 服务器地址给 LDNS,LDNS 将 http:www.a.com 解析出的 IP 地址返回给最终网民,那么在以后网民浏览器发起请求的时候,都会直接与北京联通的 CDN 节点进行流量通信,从而达到了加速的目的。 从这个调度理论上看,我们可以不难发现一个问题,就是重点标注出的“根据一般人的使用习惯”。假设网民所使用的 LDNS 地址和他自己在同一个区域,调度才有可能是准确的(后续篇章会重点描述为什么是“有可能”)。 但是举个例子来说,如果网民是北京联通的用户,但他却偏要使用深圳电信的 LDNS,LDNS 出口也同样是深圳电信的 IP 地址,那么 GLB 会误判网民位于深圳电信,分配给网民的 CDN 服务器也都是深圳电信的,后续网民会从北京联通访问到深圳电信,不但没加速,可能反而降速了。 如前文所述,由于用户使用习惯或一些其他原因,通过 LDNS 调度有可能是不准确的,因此又出现了另一种调度方式,HTTP 302 调度。 原理很简单,无论网民最初拿到的 IP 地址是否是正确的,但最终都是要和这个 IP 地址的 CDN 服务器通信的,因此 CDN 服务器可以在这时知道网民的真实地址(DNS 调度时只能间接知道网民地址,虽然 EDNS-Client-Subnet 技术可以解决问题,但尚未大规模使用)。 HTTP 协议中有一个特殊的返回状态:302。在 HTTP 服务器返回 302 状态码时,可以携带一个新的 URL(使用的是正确 IP),浏览器在拿到 302 返回状态码时,会提取其中新的 URL 地址发起请求,这样就可以做到重新调度了。 除了 DNS 调度、HTTP 302 调度,还有一种使用 HTTP 进行的 DNS 调度策略。 随着网络日新月异的发展和演进,也逐渐出现了很多鲜为人知的技术和设备,例如劫持(具体在后面的篇章里会单独阐述)。劫持后,网民所访问的目标有可能不再是真实服务器,即使是真实服务器,内容也有可能是虚假的、被替换过的,这对业务安全来说是十分危险的,这种劫持现象多出现在移动互联网(手机上网)。 为了规避这种问题,出现了一种 HTTP DNS 的调度方式,原理是通过 HTTP 报文传输 DNS 请求和应答信息。但这种方式没有任何 RFC 的支持,所以没有任何现成的操作系统直接支持,必须有自己的 HTTP DNS 客户端,来与 HTTP DNS 服务端进行通信,需要双端支持。这种做法在 APP 中使用较多。 那 CDN 是如何将用户的流量引入到 CDN 网络中的呢? 在未做 CDN 时,我们访问某个域名,直接拿到的是一个真实的服务器 IP 地址,这个显示 IP 地址的 DNS 记录信息叫 A 记录,一般是下图这个样子。 当业务需要接入到 CDN 时,用户只需调整自己的 DNS 配置信息,将 A 记录改为 CNAME 记录,将内容改为 CDN 厂商所提供的接入域名即可。 原文链接 阅读更多干货好文,请关注扫描以下二维码:
来源:OSCHINA
发布时间:2018-04-08 17:23:00
当我试图部署一个应用到SAP云平台的neo环境时: 指定Compute Unit Size为Lite: 点击Deploy按钮,遇到如下错误消息:there is no compute unit quota for subaccount: 解决方案 使用命令行neo set-quota --account wc4e460ce --user i042416 --host int.sap.hana.ondemand.com --amount lite:1 给subaccount分配一个计算单元: 分配之后,使用如下命令查看subaccount状态,确保分配成功: neo account:list-accounts --account wc4e460ce --user i042416 --host int.sap.hana.ondemand.com 之后即可成功部署: neo的console客户端命令参考 SAP help 要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:
来源:OSCHINA
发布时间:2018-06-23 19:41:00
摘要: 最为常见的【弹窗】反而是最“捉摸不定”的东西。各种类型的弹窗傻傻分不清楚,不知道在什么场景下应该用哪种弹窗。尤其是遇到“二次确认”等场景…… 因此,打算从头整理移动弹窗的基础知识,以iOS弹窗体系为切入点,从定义出发,对移动弹窗进行分类,然后分别分析每一类弹窗的应用场景,以及在使用过程中需要注意的点。 云小妹导读:作为设计童鞋的经常打交道的移动组件,反而是最捉摸不定的东西,各种类型的弹窗傻傻分不清楚,不知道在什么场景下应该用哪种弹窗。尤其是遇到“二次确认”等场景 今天的Work Like Alibaba实践分享,我们邀请 阿里巴巴TXD体验中心 的交互设计师夏天 为我们带来IOS弹窗体系分享。 1 前言 前段时间整理移动组件,发现最为常见的【弹窗】反而是最“捉摸不定”的东西。各种类型的弹窗傻傻分不清楚,不知道在什么场景下应该用哪种弹窗。尤其是遇到“二次确认”等场景…… 因此,打算从头整理移动弹窗的基础知识,从定义出发,对移动弹窗进行分类,然后分别分析每一类弹窗的应用场景,以及在使用过程中需要注意的点。 本想一次性全部整理完,但是发现iOS和Material Design两大体系下的弹窗类目繁多,相互之间又有千丝万缕的关联,因此决定拆分成四篇来仔细整理: 移动弹窗基础知识浅析系列一:iPhone弹窗体系 移动弹窗基础知识浅析系列二:安卓手机弹窗体系(Material Design) 移动弹窗基础知识浅析系列三:iPhone与安卓两大手机弹窗体系之间的关系与差异 移动弹窗基础知识浅析系列四:手机、平板、手表端的弹窗体系之间的关系与差异 2 名词解释 弹窗: 弹框是人机交互中常见的方式,常常出现于询问、警示以及完成某个插入任务,常见于网页端及移动端。弹框能使用户有效聚焦于当前最紧急的信息,也可以在不用离开当前页面的前提下,完成一些轻量的任务。 移动弹窗: 运用在移动端的弹窗,包括了手机、平板、手表等移动端设备。本文整理学习对象的是【iPhone】的弹窗体系。 模态: 模态(Modality) 是一种视图,在当前的iOS 10的人机交互指南(Human Interface Guidelines)中有如下定义: 模态视图突出焦点,因为用户只有在完成当前的任务或关闭一个信息或视图之后才能去做其它事情。 当屏幕上出现一个模态视图时,用户必须采取一个决定(点击按钮或是其它)才能退出模态化体验。一个模态视图可以占据整个屏幕、整个父视图(比如浮出层)或者屏幕的一部分。一个模态视图一般都含有“完成”和“取消”按钮来退出视图。 Modality creates focus by preventing people from doing other things until they complete a task or dismiss a message or view. When a modal view appears onscreen, the user must make a choice by tapping a button or otherwise exiting the modal experience. A modal view can occupy the entire screen, an entire parent view, such as a popover, or a portion of the screen. A modal view typically includes completion and cancel buttons that exit the view. 早在iOS 7的HIG中,模态是归属于【Temporary View】类目下,且在定义上更加直白地指出: 模态视图是完成一系列任务的有效视图。他出现在所有元素的顶部,且会阻塞所有底部元素的操作。 Modals are a useful view for tasks that require multiple commands or inputs by the user. They appear on top of everything else, and, while open, block interaction with any other interactive elements underneath. 简单理解起来,模态视图,就是在原始视图上,叠加一层蒙版,用以隔离原始视图中的所有操作,然后在蒙版上展示一层新视图,让用户更专注于完成新视图中的任务。 模态弹窗: 运用模态视图的弹窗。 非模态弹窗 运用非模态视图的弹窗。 3 移动弹窗的分类 根据是否运用模态视图,我把收集到的所有iOS的弹窗类型进行如下分类: 4 模态弹窗 4.1 对话框(Alerts,System Rating and Review Prompts) 4.1.1 定义 对话框,是我们最为常见的【弹窗】类型。 对话框 - Alerts : 对话框承载与当前状态有关的重要信息,常需要用户进行响应。对话框由标题、信息内容(可选)、一个或多个按钮、文本输入框(可选)四部分组成。除了上述可选元素以外,对话框的外观是固定的不可修改的。 Alerts convey important information related to the state of your app or the device, and often request feedback. An alert consists of a title, an optional message, one or more buttons, and optional text fields for gathering input. Aside from these configurable elements, the visual appearance of an alert is static and can’t be customized. 4.1.2 常见的使用方式 常用于信息提示、操作二次确认、邀请评分、授权等场景。 ——百度网盘,微信,蜗牛睡眠,Worktile 除了定义中提到的【文本输入框】之外,iOS还提供了默认打分的组件【System Rating and Review Prompts】: 4.1.3 使用过程中需要注意的点 标题:简短能说明问题的标题。 信息内容:根据需要可不填写。 按钮: 一般数量控制在3个以内,若需要更多的按钮,建议使用【操作列表】。 可使用加粗、颜色等方式,引导用户作出选择。 文案要具体精准,让用户明白选择之后会发生什么。而不要使用“是”“否”等语意不明的词。 符合用户预期的按钮放在右侧,【取消】按钮固定在左侧。 当有破坏性的操作的时候,一方面要突出显示具有潜在破坏性的操作按钮,另一方面要确保有【取消】按钮,保证用户能够安全地取消破坏性操作。(例如删除等。) 支持Home键关闭弹窗。 扩展组件:特殊情况下,可使用定义的扩展组件。例如文本输入框、打分组件等。 操作方式:由于必须要获取用户明确的响应,因此只有选择按钮才能关闭弹窗。(点击蒙版无法关闭弹窗) 4.2 操作列表(Action Sheets,Action Views) 4.2.1 定义 操作列表 - Action Sheet 操作列表是一种特殊的对话框,是对操作动作的响应,显示当前操作场景下相关联的多个选项。用于让用户开始任务,或者在执行潜在的破坏性操作前,进行二次确认。 An action sheet is a specific style of alert that appears in response to a control or action, and presents a set of two or more choices related to the current context. Use an action sheet to let people initiate tasks, or to request confirmation before performing a potentially destructive operation. 操作视图 - Activity View 操作视图是app快捷任务的展示面板。用户点击面板上的任务,可以直接执行相应的任务。 An activity is a task, such as Copy, Favorite, or Find, that’s useful in the current context. Once initiated, an activity can perform a task immediately, or ask for more information before proceeding. Activities are managed by an activity view, which appears as a sheet or popover, depending on the device and orientation. 4.2.2 常见的使用方式 操作列表常被用于单选操作,以及 删除操作的二次确认。 (单一操作) ——哔哩哔哩,teambition,照片,微信(未使用原生弹窗) 操作视图常被用于分享操作。 ——Safari,钉钉,微信,UC 4.2.3 使用过程中需要注意的点 确保有一个【取消】的按钮。 突出显示具有潜在破坏性的操作按钮。 尽量避免列表的滚动,如选项过多,则需要留出视觉线索。 对于【操作视图】,需要明确的应用图标和操作名称,用于清晰地描述任务。 4.3 浮出层(Popover,Edit Menus,Home Screen Quick Action Menus) 4.3.1 定义 浮出层 - Popovers 浮出层是一种暂时性的视图,他出现在用户点击区域的顶层。典型的浮出层包括一个箭头,指向浮出层出现的位置。浮出层可以是模态的,也可以是非模态的。 A popover is a transient view that appears above other content onscreen when you tap a control or in an area. Typically, a popover includes an arrow pointing to the location from which it emerged. Popovers can be nonmodal or modal. 编辑菜单 - Edit Menus 用户可以在文本、网页、图片等地方,使用长按、双击的手势唤起【编辑菜单】。他包含了一些相关联的编辑操作,比如复制、粘贴等。 People can touch and hold or double-tap an element in a text field, a text view, a web view, or an image view to select content and reveal edit options, such as Copy and Paste. 主屏快捷操作菜单 - Home Screen Quick Action Menus 快捷主屏操作菜单,是通过3D Touch唤起的快捷菜单。 Home screen quick actions are a convenient way to perform useful, app-specific actions right from the Home screen, using 3D Touch. 4.3.2 常见的使用方式 严格意义上的浮出层,能够包含【导航栏、工具栏、标签栏、表格、收藏、图片、地图】等各种元素,所以由于展示空间的问题,只能使用在iPad端,在手机端对应的是【全屏模态视图(Full-Screen Modal Views)】。 但是,浮出层的明确指向性和便捷性,依旧非常适合用于手机端的菜单选择,因此很多app都自己设计了小型的Popovers: ——微信,钉钉,手机淘宝,支付宝 编辑菜单,常用于对文本和聊天记录的编辑。 ——微信,钉钉,备忘录,UC 主屏快捷操作菜单,是iOS独有的交互形式,只在主屏中使用,用于快速执行应用的常用任务。 ——iOS主屏 4.3.3 使用过程中需要注意的点 显示符合上下文情景的操作选项,并用通用的文案描述。 尽可能地减少选项数量,只显示最有意义的操作。 使用标准手势唤起菜单。 根据唤起的位置,自动调整菜单的位置。 对于【编辑菜单】: 自动选择相关联的词组。 不要加入【编辑】按钮。 支持【撤销/重做】操作。 4.4 模态视图(Modal View) 4.4.1 定义 一个模态视图可以占据整个屏幕、整个父视图(比如浮出层)或者屏幕的一部分。 A modal view can occupy the entire screen, an entire parent view, or a portion of the screen. 这里分析的【模态视图】,区别于【对话框】,占据了更大范围的屏幕,内部包含更多的操作。 4.4.2 常见的使用方式 根据占据屏幕的方式及范围,可以分为【全屏、半屏、中央】三种类型,其中【全屏、半屏】常包含复杂表单: 全屏,常见于“新建后发送、选择后下载”等场景。 ——网易邮箱-写邮件,钉钉-DING,微信-转发消息,腾讯视频-缓存 半屏,常见于“侧边导航、选择器”等场景。 ——滴滴出行,大众点评,手机淘宝,支付宝 中央,常见于“宣传、引导用户”等场景。 ——百度糯米,滴滴出行,美团,teambition 4.4.3 使用过程中需要注意的点 确保模态视图中的任务是简练严谨的,让用户能够聚焦高效地完成任务。 提供明显且安全的退出模态视图的方式。 对于【全屏/半屏】: 未点击【保存/确认/完成】等明确的按钮之前,所有的修改都不会生效。 模态视图多从边缘进入。 点击蒙版即可关闭模态视图。 5 非模态弹窗 5.1 透明指示层(UIProgressHUD) 具体的定义没有找到,对应的是安卓独有的的Toast,据说iOS称之为 HUD(head up display) 。目前未开放接口,只应用在原生系统的音量键。 但是在很多APP中,大家已经习惯将广义上的Toast用于状态的提示: ——iOS音量键,手机淘宝,大众点评,腾讯视频 5.2 通知(Notifications) 5.2.1 定义 无论手机是锁屏状态还是使用状态,app应用都能通过通知,第一时间传递给用户重要信息。 Apps can use notifications to provide timely and important information anytime, whether the device is locked or in use. 5.2.2 常见的使用方式 运行中的顶部banner,重按之后,会展开并呼出【操作列表 Action Sheet】。 5.2.3 使用过程中需要注意的点 提供精炼有价值的信息。 注意通知发送的频率和时机。 考虑3D Touch重按之后的展示细节内容,以及相关的操作按钮。 6 参考文献 认识移动端弹框, https://mp.weixin.qq.com/s/9XyiKTiXYaIHcFHDbpvLEg Human Interface Guidelines(iOS 10,2017.06), https://developer.apple.com/ios/human-interface-guidelines/overview/design-principles/ The iOS Design Guidelines(iOS 7,2015.9.28), http://ivomynttinen.com/blog/ios-design-guidelines 几种弹窗设计模式(iOS端), http://www.jianshu.com/p/63eb8fad9329 实用干货!UI设计师需要了解的 APP弹窗体系, http://www.uisdc.com/app-popup-ui-system 注1:本文是基于iOS 11的人机交互指南(Human Interface Guidelines)、网上大神们的文章、个人经验总结梳理而成,还望大家不吝赐教,提出宝贵的意见或建议。 注2:若内容涉及侵权,请联系管理员,我们将第一时间删除相关内容。 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-06-22 18:15:00
摘要: 东方明珠新媒体如何基于阿里云,搭建了面向第三方的视频SaaS服务?6月8日,上海云栖大会视频专场中,东方明珠新媒体股份有限公司云计算中心的副总周少毅带来了《东方明珠视频云》为题的精彩演讲,介绍了东方明珠视频云的搭建过程。 东方明珠新媒体如何基于阿里云,搭建了面向第三方的视频SaaS服务?6月8日,上海云栖大会视频专场中,东方明珠新媒体股份有限公司云计算中心的副总周少毅带来了《东方明珠视频云》为题的精彩演讲,介绍了东方明珠视频云的搭建过程。 东方明珠新媒体股份有限公司拥有国内最大的多渠道视频集成与分发平台及文化娱乐消费资源,为用户提供丰富多元、特色鲜明的视频内容服务及一流的视频购物、文旅消费、影视剧及游戏等文娱产品,是上海广播电视台、上海文化广播影视集团有限公司(SMG)旗下统一的产业平台和资本平台,在2017年中国互联网企业100强中排名16位。 在分享中,周少毅表示:起初,各行业、各企业都想建立自己的网站,而现在,各行业、各企业都希望在网站中加入视频,因为视频在传播中最有震撼力,这是一个市场需求。但是并不是所有企业都可以投入如此多的人力和时间,所以东方明珠基于阿里云视频服务,建立了一套完整的OTT平台SaaS服务,让非专业公司拥有视频服务像搭建一个网站一样简单。 整体的视频流处理通常分为五大流程:素材上传、审核、视频剪辑、转码发布、展现播放,基于东方明珠这套视频SaaS服务,全部工作都可以直接通过网页完成,功能可以非常轻便快捷的实现。视频的SaaS服务可以应用于门户网站、新零售、医疗、新媒体等众多行业场景中,任何需要视频为媒介来宣传,或者以视频为载体进行培训的企业都可以接入,东方明珠新媒体内部客户已经开始使用了。 周少毅也提到,在使用阿里云视频服务的过程中,有几点对他比较有吸引力。第一是视频云的云端剪辑能力,它让视频内容编辑可以很轻量的完成;第二是内容安全,HLS标准加密解决方案能够支持加密传输,配合存储中的安全、攻击防护、劫持抵御等,提高整个视频传输链路中的安全性;第三是云服务无需硬件采购,没有使用边界,在任何时间、地点都可以轻松登录云端;第四是弹性投资,按照实际用量付费。 东方明珠视频SaaS服务采用的阿里云产品图 对于视频云的HLS标准加密方案,周少毅评价整体流程既简单又高效、既安全又方便,对方案非常满意。在本次分论坛现场,他也分享了一些实践流程及细节。 HLS标准加密视频加密流程相对比较简单,从KMS拿到密钥,告诉VOD,VOD把这个视频加密,并且把加密密钥写在RDS中就好了,整个加密在转码过程很高效地就完成了。 但是加密播放是比较复杂的,因为涉及到不同种类的终端。HLS标准加密最大的好处就是加密的工作都在服务端完成,播放器端几乎不用改,播放明文和播放非加密的流程是一样的,省去了复杂的适配调整。同时,关于KEY的发放、加密内容的传输的安全级别也是很高的。 周少毅表示作为客户,整个使用的过程非常简单,客户端发起请求加密视频之后,对于EPG或者AAA来说,只要去请求服务,拿到Token,放到URL中,播放URL返回给客户端,就结束了。 除了VOD HLS标准加密解决方案之外,东方明珠视频SaaS平台也采用阿里云标准大数据解决方案,整个过程如下图。 在分享的最后,周少毅为现场的开发者和企业提出了一些建议:我们做事情还是不能从轱辘做起,最好基于现有的平台,如果能采用SaaS,你的人力投入可能是基本是零;如果能用PaaS,投入可能是几个人。如此才能快速地具备能力,应对当今迅速变化的市场环境。 原文链接
来源:OSCHINA
发布时间:2018-06-22 17:02:00
摘要: 一个大的商业项目,如何能做到如期完工并准时交付,是有一套标准化的流程和体系来支撑的。 项目管理并不是一个陌生的话题,就像《人月神话》里面提到的阿波罗计划、曼哈顿工程都是非常经典的案例。对于很多新同学来讲,对项目管理没太大感觉,认为总是在沟通和确认一些细节,对风险的识别有太多体感。其实对于一个大的商业项目,如何能做到如期完工并准时交付,是有一套标准化的流程和体系来支撑的。项目管理是一项综合素质要求很高的工作,像其中的理论工程体现在: 项目管理的九大知识领域:成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。每个都是一个专项,需要有理论和长期的经验积累。 项目管理中的铁三角:时间、成本和范围,如何把控好这三方面将决定项目的质量及最终的交付成果。 项目管理的5个过程:启动,计划,执行,控制,收尾。这种仪式感能让项目组的干系方对项目有一个整体的认识和了解,有一根主线来明确大家要走的方向。 单纯讲理论只能是纸上谈兵了,只有和实践相结合才会有产出和结果。但最好的实战是能把这些理论中的流程、管理及过程等融合到系统中,让PM及项目组同学使用系统即可完成对项目的管理。今天就结合CBU 1220商人节大促来谈谈我们是如何借用云效和大促管理中心来做跨多团队协同的项目管理的。 无论是大市场的日常业务还是大促活动,17年对于B类业务是不同寻常的一年,尤其在大促方面表现非常强劲,GMV和买家数都在不断创新高,且网站、渠道、销服等各部门都在深度联动和融合。就像我们的口号“CBU在一起,就不一样”。 要应对几何级增长的大促要跨多个团队协同,有非常多的干系方,包括运营、产品、技术、规则、法务、渠道、销服及客满等,且大促的战线拉的非常长,从前期的招商、营销玩法、会场搭建、氛围配置、流量分配等,为了让PM能关注到各自负责的主业务,且交叉的细节不会有遗漏,摸索出了云效+大促管理中心的线上项目管理模式,能让各角色在系统上完成信息流转和确认,才能保证大促不出问题且有确定性。如图2所示。 图 2 大促协同及操作流程线上化 1220商人节从筹备到爆发共有2个月时间,完成240+需求,18个大项目,投入了100多位技术小二,1900多人日。感谢云效团队的吴雪娇在前期给我们介绍了 云效 是如何采用项目集来管理双11大促,1220商人节我们也将其应用到了B类大促中。这里总结下使用过程,也让后续其他团队在应对跨多团队协同的大项目时可以借鉴。过程如图3所示。 图 3云效跨多团队协作项目管理过程 1、项目集规划: 对于一次B类的营销大促涉及到很多部门,也有非常多的干系方。为了保障大促的整体有序推进,会有大PM和各模块的子PM。在项目启动之初,技术大PM首先要和产品PM确定本次大促需求的大致范围,如营销玩法、招商、会场等,做到心中有数。这种大促类的需求变更是常有的事,前期要做的是尽量控制这种变更越少,范围越小越好。其次,要尽快敲定各模块的子PM人选,把人员定下来后才能做好项目分解,保证后续的有序推进。 项目集用来管理跨多团队协同的项目,它可以将相似的或归属于同一个领域的项目划归为一个项目集。如招商项目集即是将横向、行业等涉及到招商的需求都归结到一起,便于PM从横、纵方面整体跟进。大PM要根据积累的经验及本次大促的基本的需求范围规划出大促的项目集结构。如图4所示。 图 4 1220商人节大促的项目集结构 2、框架搭建: 项目集规划好后,即可在云效上搭建项目管理的框架了。只要前期规划合理,框架搭建起来会非常便捷,同时也利于后期需求的关联和归属划分。如图5所示。 图 5 1220商人节大促项目集框架 在框架搭建时有几个关键点需要特别关注: 项目的整体进度:大PM要根据各模块的进展来评估出大促项目的整体进展,为后续汇总项目周报做准备。 项目的关键里程碑点:确定好项目大的关键里程碑点,如大促的KO、招商上线、会场上线,功能预演等,并安排好各个模块对应的负责人和check人员。 项目风险:大PM要识别项目中的风险,做到及时沟通及资源协调。风险的识别可以来自于对关键项目的把控,也可以来自于子PM对风险的上报。每周的项目周会或周报上要对风险有专门的版块来识别,并给出有效的应对措施。 项目干系人设置:大PM要将赋权给各模块的PM及产品、运营、PE、DBA等角色。让各角色都能对所负责的项目集进行操作。 3、子项目集管理:将上述规划好的项目依次建立子项目集,并设定各模块的PM。子PM需要做的也是对所负责模块的项目的进度把控、里程碑点的设定、风险的识别及对需求的管理。如图6所示。 图 6 子项目管理 对于大促中涉及到跨多团队的横向、纵向等需求的管理,可以有不同的视图快速查看完成的进展及所处的阶段。PM只需要及时的跟进并更新相应的视图区块即可。如图7所示。 图 7 子项目及需求的各种管理视图 4、需求及项目跟进: 再往下分解,即是对每个项目或需求的管理。PD提交需求时,还是按照原有的产品线来提交,如旺铺的需求提交到旺铺的产品线,招商的提交到运营平台线。如果该需求或项目和这次大促相关,只需要将其关联到对应的项目集上,大促这个版块的PM即可以将对该需求进行跟踪及管控。具体如图8所示。 图 8 需求的关联及进度管理 一般经过这几个步骤的设置,各个PM包括老板即可非常清晰的看到一次大促的进展、风险及各个模块的健康情况。当然系统里面实现的只是一个工具,能方便大家更透明的做项目管理,且将流程和标准做到系统中。但真正要做到一次大促不出问题且有较强的确定性,很多时侯还是要靠PM及开发同学的责任心及相互补位才能做到。 原文链接
来源:OSCHINA
发布时间:2018-06-22 16:43:00
摘要: 一个大的商业项目,如何能做到如期完工并准时交付,是有一套标准化的流程和体系来支撑的。 项目管理并不是一个陌生的话题,就像《人月神话》里面提到的阿波罗计划、曼哈顿工程都是非常经典的案例。对于很多新同学来讲,对项目管理没太大感觉,认为总是在沟通和确认一些细节,对风险的识别有太多体感。其实对于一个大的商业项目,如何能做到如期完工并准时交付,是有一套标准化的流程和体系来支撑的。项目管理是一项综合素质要求很高的工作,像其中的理论工程体现在: 项目管理的九大知识领域:成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。每个都是一个专项,需要有理论和长期的经验积累。 项目管理中的铁三角:时间、成本和范围,如何把控好这三方面将决定项目的质量及最终的交付成果。 项目管理的5个过程:启动,计划,执行,控制,收尾。这种仪式感能让项目组的干系方对项目有一个整体的认识和了解,有一根主线来明确大家要走的方向。 单纯讲理论只能是纸上谈兵了,只有和实践相结合才会有产出和结果。但最好的实战是能把这些理论中的流程、管理及过程等融合到系统中,让PM及项目组同学使用系统即可完成对项目的管理。今天就结合CBU 1220商人节大促来谈谈我们是如何借用云效和大促管理中心来做跨多团队协同的项目管理的。 无论是大市场的日常业务还是大促活动,17年对于B类业务是不同寻常的一年,尤其在大促方面表现非常强劲,GMV和买家数都在不断创新高,且网站、渠道、销服等各部门都在深度联动和融合。就像我们的口号“CBU在一起,就不一样”。 要应对几何级增长的大促要跨多个团队协同,有非常多的干系方,包括运营、产品、技术、规则、法务、渠道、销服及客满等,且大促的战线拉的非常长,从前期的招商、营销玩法、会场搭建、氛围配置、流量分配等,为了让PM能关注到各自负责的主业务,且交叉的细节不会有遗漏,摸索出了云效+大促管理中心的线上项目管理模式,能让各角色在系统上完成信息流转和确认,才能保证大促不出问题且有确定性。如图2所示。 图 2 大促协同及操作流程线上化 1220商人节从筹备到爆发共有2个月时间,完成240+需求,18个大项目,投入了100多位技术小二,1900多人日。感谢云效团队的吴雪娇在前期给我们介绍了 云效 是如何采用项目集来管理双11大促,1220商人节我们也将其应用到了B类大促中。这里总结下使用过程,也让后续其他团队在应对跨多团队协同的大项目时可以借鉴。过程如图3所示。 图 3云效跨多团队协作项目管理过程 1、项目集规划: 对于一次B类的营销大促涉及到很多部门,也有非常多的干系方。为了保障大促的整体有序推进,会有大PM和各模块的子PM。在项目启动之初,技术大PM首先要和产品PM确定本次大促需求的大致范围,如营销玩法、招商、会场等,做到心中有数。这种大促类的需求变更是常有的事,前期要做的是尽量控制这种变更越少,范围越小越好。其次,要尽快敲定各模块的子PM人选,把人员定下来后才能做好项目分解,保证后续的有序推进。 项目集用来管理跨多团队协同的项目,它可以将相似的或归属于同一个领域的项目划归为一个项目集。如招商项目集即是将横向、行业等涉及到招商的需求都归结到一起,便于PM从横、纵方面整体跟进。大PM要根据积累的经验及本次大促的基本的需求范围规划出大促的项目集结构。如图4所示。 图 4 1220商人节大促的项目集结构 2、框架搭建: 项目集规划好后,即可在云效上搭建项目管理的框架了。只要前期规划合理,框架搭建起来会非常便捷,同时也利于后期需求的关联和归属划分。如图5所示。 图 5 1220商人节大促项目集框架 在框架搭建时有几个关键点需要特别关注: 项目的整体进度:大PM要根据各模块的进展来评估出大促项目的整体进展,为后续汇总项目周报做准备。 项目的关键里程碑点:确定好项目大的关键里程碑点,如大促的KO、招商上线、会场上线,功能预演等,并安排好各个模块对应的负责人和check人员。 项目风险:大PM要识别项目中的风险,做到及时沟通及资源协调。风险的识别可以来自于对关键项目的把控,也可以来自于子PM对风险的上报。每周的项目周会或周报上要对风险有专门的版块来识别,并给出有效的应对措施。 项目干系人设置:大PM要将赋权给各模块的PM及产品、运营、PE、DBA等角色。让各角色都能对所负责的项目集进行操作。 3、子项目集管理:将上述规划好的项目依次建立子项目集,并设定各模块的PM。子PM需要做的也是对所负责模块的项目的进度把控、里程碑点的设定、风险的识别及对需求的管理。如图6所示。 图 6 子项目管理 对于大促中涉及到跨多团队的横向、纵向等需求的管理,可以有不同的视图快速查看完成的进展及所处的阶段。PM只需要及时的跟进并更新相应的视图区块即可。如图7所示。 图 7 子项目及需求的各种管理视图 4、需求及项目跟进: 再往下分解,即是对每个项目或需求的管理。PD提交需求时,还是按照原有的产品线来提交,如旺铺的需求提交到旺铺的产品线,招商的提交到运营平台线。如果该需求或项目和这次大促相关,只需要将其关联到对应的项目集上,大促这个版块的PM即可以将对该需求进行跟踪及管控。具体如图8所示。 图 8 需求的关联及进度管理 一般经过这几个步骤的设置,各个PM包括老板即可非常清晰的看到一次大促的进展、风险及各个模块的健康情况。当然系统里面实现的只是一个工具,能方便大家更透明的做项目管理,且将流程和标准做到系统中。但真正要做到一次大促不出问题且有较强的确定性,很多时侯还是要靠PM及开发同学的责任心及相互补位才能做到。 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-06-22 16:41:00
摘要: 2018年云栖大会的主题为:驱动数字中国。那么,传统企业为什么践行数字化转型呢?在数字化转型中,阿里云又可以在多媒体这个垂直领域提供什么样的帮助呢?在6月8日的上海云栖视频专场中,阿里云视频云资深技术专家李彬围绕大会主题,展开了一场关于传统企业数字化转型与多媒体创新的演讲, 首先,李彬认为:数字化转型不是目的,是为了加速创新。 2018年云栖大会的主题为:驱动数字中国。那么,传统企业为什么践行数字化转型呢?在数字化转型中,阿里云又可以在多媒体这个垂直领域提供什么样的帮助呢?在6月8日的上海云栖视频专场中,阿里云视频云资深技术专家李彬围绕大会主题,展开了一场关于传统企业数字化转型与多媒体创新的演讲, 首先,李彬认为:数字化转型不是目的,是为了加速创新。从计算机诞生开启,各种计算能力就开始飞速发展,数字化的经济渐渐繁荣,创新速度也越来越快,数字化对传统行业的渗透也越来越多。 纵观历史,从60年代开始,最开始有了大型机及数据库,带来了在编程语言和计算机算法方面的技术进展,带来了商业分析、数据库系统的商业模式产出。到了70年代出现了个人电脑,每个人的工作效率逐渐增强,到80年代开始有了商业软件,使企业流程有了很大的提升,从90年代开始,有了互联网和电子商务,即时通讯使个人工作效率极大提高。2000年左右开始有了移动宽带,人实时在线,随时与别人互联。之后很快,我们有了社交网络,催生了数字广告,商业营销与变现从传统的线下转移到了线上。网络视频也随之出现,从最初的UGC视频平台,逐渐渗入到各行各业,人们开始用视频来了解世界、分享生活。而在2010年之后,大数据、人工智能、机器学习这些算法又带来了新的创新,视频和语音不再单纯是内容载体,它变成了一种可以去索引、搜索、联想、分析的能产生更多价值的存在。 全球数字化经济发展趋势 具体到多媒体这个领域中,传统教育、工业、医疗等各个行业,都可以利用视频这种内容模式,使得自身生产效率提升,加速商业发展。但是传统多媒体系统开发一般都会遇到这样的三角: 如果想要做出很好的品质,并且实现的很快,那可能会很贵 如果想要比较低廉的预算快速实现,那系统的品质相对就差 如果又想要好的品质,又要便宜,可能会需要花费大量时间 为了能到达三个圆形中间的区域,企业可以考虑采用云原生的多媒体系统,尽量一开始就从云的角度去考虑,构建系统。首先,采用云端的服务,会大大缩短开发周期。另外,云原生系统可以降低总体拥有成本,这里就包括硬件成本、带宽成本、开发成本、时间成本等,比如接入阿里云点播服务并使用阿里云提供的视频端SDK,很短时间,用并不多的开发力量就可以完成一个完整的在线视频应用或者是一个短视频社区。最后,技术演进的路径可以使开发更加灵活,传统情况下,如果你选定了一套多媒体系统的架构,那接下来开发必须沿着这个方向去演进,比较受限。而采用云原生的多媒体系统,很多时候都是API和SDK的调用,对未来的升级和扩展没有更多的负担。 阿里视频云的定位是为用户提供基础的视频服务,从高可定制、高可扩展性、高性能、高质量的视频处理(AI)、存储、传输PAAS服务,到一站式端到端视频解决方案,各种体量,各种模式(toC或者toB)的用户在这里都可以在此之上搭建自己的应用及服务。 一、灵活的视频PAAS服务 在阿里云官网上提供的媒体处理、视频直播、视频点播三个产品中,所有的功能都支持通过API调用,各种功能可自由选择,搭配使用,不存在任何限制。使用者只为自己用的功能付费,不用担心产生任何额外的费用。 二、一站式的视频解决方案 如果用户不想花费太多精力去开发和维护视频应用,那也可以采用一站式的视频解决方案。下图中的短视频、点播解决方案,就包括了从终端视频导入、拍摄了,到云端的媒体管理、安全保护、在线编辑、视频识别,再到终端的播放、审核与统计等等,用几天的时间就可以搭建起一个完整的视频应用。 同时,阿里云提供采集、播放端的SDK到云端的整套服务,常见的互动直播、移动直播、赛事直播都可以采用这套方案,快速上线。 在最后,李彬也分享了几个客户案例。刚刚完成互联网史上最大的数据迁移的115网盘就是视频云的服务客户,媒体处理的能力帮助115实现了视频在线的实时点播观看的功能。同时,优酷的媒体处理、视频内容的分发都是基于阿里视频云完成,因为有了优酷这个内部的大客户,所以视频云的产品能力得到了验证和打磨,并且能始终保持高弹性和高稳定性。另外,传统教育行业对视频内容保护有较高的要求,阿里视频云能够提供从视频加密、到终端播放SDK,到互动白板,短延时直播的方案支持。 原文链接
来源:OSCHINA
发布时间:2018-06-22 16:18:00
消息触达能力是物联网(internet ofthings, IOT)的重要支撑,而物联网很多技术都源于移动互联网。本文阐述移动互联网消息推送技术在物联网中的应用和演进。 一、物联网架构和关键技术 IP互联架构已是物联网的事实标准(有关物联网TCP/IP层关键技术将另文阐述,敬请关注)。本文所讲的消息推送技术是基于TCP/IP协议的应用层协议技术。 我们先进一步抽象基于IP架构的物联网组成,如下图(忽略internet和路由等基础技术): 可见,核心组成就是物联设备things、网关和云端。物联设备分为两类,一类是其自身天然支持TCP/IP而能直接接入物联网,如wifi、GPRS/3G/4G等设备;另一类是其未能支持IP协议而需要网关(协议转换)来接入物联网,如Zigbee、蓝牙等设备。对于蓝牙设备而言,手机其实是一个网关。 手机通过自身的蓝牙跟外设蓝牙设备通信,并将消息通过手机的wifi或者3G/4G模块与云服务端通信。 从场景的角度来分析,物联网最终是给人类服务的,而手机是人类体验的最直接入口。因此在上图中可以单独添加手机组成部分,并将其与一般意义上的网关区分出来。这样物联网核心组成就是:设备端—网关—云端—手机。 从应用层开发技术的角度来看,物联网应用是基于TCP/IP架构建立,在屏蔽底层的网关协议转换的基础上,物联网应用的组成部分就是:设备端—云端—手机。 OK,有了以上的介绍,我们就从物联网应用的角度来分析设备、云端、手机直接的消息推送技术,它包括云端和设备端的双向通信技术、手机和云端的双向通信技术。 二、移动互联网通信模式 互联网有B/S和C/S两种通信模式。在移动互联网领域,APP是以C/S的方式以client的角色跟服务器server进行通信;而微信是一个超级APP,其是通过内置浏览器让用户进行H5编程以获得操控硬件设备的能力,因此微信硬件平台的通信模块是B/S模式。 移动互联网B/S技术跟传统互联网没有区别,微信内置浏览器支持H5,因此可以获得很好的平台扩展性。我们近期重点关注基于微信硬件平台的物联网,因此就围绕B/S模式的消息推送技术讲述其演进。 HTTP协议是B/S的基础,HTTP有GET和POST两种方式。 三、消息推送技术演进 1.HTTP单向通信 浏览器使用HTML文本标记语言,即浏览器通过HTTP协议向服务器发起请求(请求内容包括URL,即我们常说的网址),服务器将URL对应的HTML内容通过HTTP协议作为响应传送回给浏览器。 1)手机端。微信端因为有内置浏览器,其天然支持前端页面。 2) 云端对手机端推送。云端使用JSP/PHP等技术开发设计前端网页和简单的逻辑即可。 3)设备端。设备端上线时或者访问服务端参数等内容时需要模拟HTTP协议(C语言)向服务器发起请求,而请求的格式一般不使用HTML,而是使用较为简单的XML或者JSON协议格式。 4)云端对设备端推送。云端使用HttpServlet(即使用http协议的servlet)对设备的HTTP请求进行响应,回复XML或者JSON格式的消息。 5)缺点。这种方式通信方式的特点就是一请求一响应,总是要客户端向服务器发出请求,服务器才给予响应。服务器从来都不会主动给客户端发消息,而且在客户端发出请求后,服务器也只是回复一次。这种HTTP单向通信方式在互联网领域发挥巨大的作用,就是服务器端可以是无状态的,极大地简化了服务器的服务流程,提高效率。但在物联网领域,我们要求的是双向的通信能力。服务端要能主动给设备端或者手机发出消息。 在这种模式下,我们怎么做双向通信呢?唯一的做法就是客户端不断地发出请求(或者周期性),服务器不断地给予回复。这种模式下的缺点显而易见:一是网络负载重,服务器每次响应后都会关闭连接,所以每次通信都得重新握手。HTTP协议的头内容的长度可不小。二是实时性差。一般设备端都是周期性地轮询服务器是否有新的消息,轮询的方式是不能获得好的实时性的。三、浏览器端每次发出请求是以HTML全部内容来响应的,消息长度过大,在这种情况下,会发现浏览器页面不断地刷新。 2.Ajax轮询 Ajax技术是浏览器支持的一种JavaScript技术。其能够局部改善用户体验技术,让用户在不察觉浏览器页面刷新的情况向服务器发出请求,并获得响应。其原理是: 1)微信浏览器发出URL页面请求,服务器响应HTML页面内容。 2)HTML页面使用js调用XMLHttpRequest来向服务器发出异步通信请求。 3)服务器响应XML格式数据给浏览器页面。 4)HTML页面使用DOM模型来动态刷新页面元素。 Ajax技术是微信硬件平台框架中推荐的页面交互技术,但其本质还是遵守HTTP单向通信的规则,只是页面交互时不需要刷新整个页面。其双向通信实时性问题依然未能解决。 3.Websocket Websocket是HTML5支持的一种新的协议,它能够真正支持浏览器和服务器之间进行双向通信。Tomcat7及以上版本也已经支持Websocket API。 1)为了能够兼容浏览器HTTP协议,Websocket规定在第一次发起请求时依然要发出符合HTTP协议规范的Header,但其Connection域的值是Upgrade,并增加Upgrade域,值是socket,即告知服务器,即将建立的通信是Websocket双向通信。服务器如果接受,会返回101给客户端进行协议切换。 2)接下来的通信将不再以HTTP作为传输协议,而是使用Websocket规定的数据格式进行通信,其分为控制帧和数据帧。控制帧是发出心跳帧(ping),而服务器响应pong,还有结束帧;数据帧就是真实数据格式,其格式头只有6个字节(2个字节头和4个字节的掩码),后面就是真实的数据(经过掩码转换)。比HTTP格式头的长度要小多了。 3)客户端和服务器之间是一直保持连接,直到close,当前期间要发发2个字节的3字节的ping帧。 可见Websocket比ajax有了极大的改进。其不仅省掉经常要连接握手,还简化的协议的格式,最重要的是实时性得到保证,因为双方是真正的全双工通信。 微信浏览器客户端支持Websocket,服务器使用Tomcat7以上的WebsocketServlet类,设备端要根据Websocket协议用C语言来模拟通信。 我们在用设备端模拟Websocket通信协议时一般会先看协议,再用HttpWatch等工具来抓包,抓到的头是GET ws://ip:port/path,如果在C语言也是这样模拟发包则会报400 bad request。因为C语言利用socket建立通信时已经利用了IP和port了,其发的第一个包的头是GET/path即可,不能在其前面加上ws://ip:port/。 4.MQTT 以上的分析都是将移动互联网的技术运用到物联网,其都有一个特定就是建立连接时会传送URL地址,由两个角色是客户端和服务器,这种架构我们一般称为是RESTful架构(另外,还有SOAP 面向应用的web services架构)。RESTful架构在互联网得到越来越广泛的运用,但物联网除了互联之外,还有其独有的特征,就是其终端设备的资源有限、低功耗运用场景、网络连接环境差(时不时断开连接)等。用C语言模拟的方式来使用RESTful架构(如Websocket)会使得终端的负荷较重,而且服务器发给终端设备的消息有可能因为断开连接而收不到。 MQTT是IBM针对物联网退出的一种轻量级协议,建立于TCP/IP层协议之上。其是物联网的重要组成部分,可能会成为物联网的事实标准。其具有QoS,能够缓冲消息,并通过重传机制保证终端设备收到消息;其消息格式极其简化,最短是两个字节;其提供订阅和发布模式,高效推送消息。 MQTT有三个角色,包括服务器代理、订阅者和发布者。 1)启动服务器代理。 2)订阅者向服务器代理订阅相关主题。 3)发布者向服务器代理发布主题信息。 4)服务器代理想所有订阅该主题的订阅者推送消息。 MQTT有C/C++语言和JAVA包实现。需要明确的是,MQTT更适用于设备终端和手机APP socket通信,而不能支持浏览器使用。如果要支持微信浏览器应用,还需要增加类似WebsocketServlet技术给浏览器提供支持,这时MQTT以JS接口进行封装,并被调用完成消息推送。 5.CoAP CoAP是受限制的应用协议(ConstrainedApplication Protocol)的代名词。其基于UDP协议,也就是在设备终端上只需要底层实现UDP协议,而不需要实现较为复杂的TCP协议。这种协议用得比较小。笔者也没有用C语言模拟过,就不展开了。 从开发的角度,无线接入是物联网设备端的核心技术,身份设备管理和消息推送技术是物联网云端的核心技术。而从场景体验的角度,除了前者,还要包括手机的前端开发技术。
来源:OSCHINA
发布时间:2018-07-05 17:19:00
Docker从1.12引入了swarm模式,swarm mode用来管理集群化的docker engines,被称作swarm。可以使用docker CLI来创建swarm,给swarm上部署应用,管理swarm的行为等等。。你可以创建一个集群包含一个或者多个docker engines,这个被叫做swarm mode。一个swarm包含了多个node,node可以是物理机、虚拟机等等。node包含了两个角色:managers、workers manager node: 维护集群状态 调度服务 服务swarm模式下的HTTP API manager之间采用raft协议通讯,所以可以通过部署多台managers建立manager的高可用,但是manager必须是奇数个 worker node: work nodes就是docker engine实例,唯一的用途就是执行容器。你可以创建一个只有一个manager的swarm,但是不能创建一个只有一个node,确没有manager的swarm集群。 在部署一个app容器镜像到docker的swarm模式的时候,一般是创建一个service。当你创建一个service的时候,你要指定那个镜像会被使用,并且要在镜像里面执行上面命令,你也可以指定这个服务的一些其他选项: 在swarm模式下,这个service对外暴露的端口 一个overlay网络用来连接到swarm下的其他service cpu和mem的使用配额限制 一个滚动升级策略 这个镜像在运行时的副本个数 有两种类型的service部署模式:replicated和global 在replicated service模式下,你可以指定该service你想有多少个task在运行,比如,你可以指定一个http服务有三个replicas,每个都提供相同的内容 在global service模式下,该service在每一个node上运行一个task,这里不需要预先设定task的数量,任何时候只要你在集群里面加入新的node,调度系统都会在该新node上自动部署该服务,这种场景适合在机器上部署监控客户端等等。 docker允许你创建service,service可以运行tasks,一个service是一个描述的最终状态,task是工作的work,work通过swarm来调度到node节点上,服务创建使用的是下面的流程: 使用docker service create创建服务 请求到达Docker manager节点上 Docker manager节点调度该请求运行到一个workers node上 每个service可以启动多个tasks实例 每个tasks实例都有自己的生命周期 一个task会一直运行到它的任务完成,如果一个task停止了,该task是不会再次运行的。task会通过一系列状态最终完成或者失败,task一般有以下状态: NEW 初始化task PENDING 阻塞状态 ASSIGNED 分配到node状态 ACCEPTED 被node接收状态 PREPARING 准备状态 STARTING 启动状态 RUNNING 运行状态 COMPLETE 正常运行完毕状态 FAILED 运行失败状态 SHUTDOWN docker关闭该task状态 REJECTED work node拒绝该task状态 ORPHANED node节点宕机太长状态 REMOVE 当你第一次安装并启动docker engine时,swarm模式是默认被禁止的。当swarm模式打开后,你可以通过swarm service来管理services,有两种方式可以运行在swarm模式: 创建一个新的swarm 加入现有的swarm docker engine创建swarm的流程: 交换当前node到swarm模式 创建一个名为default的swarm 指定当前node为当前swarm的leader manager 命名该node的名称为该主机名 配置manager监听在本机的2377端口 设置当前node为active状态,这意味这该node可以接收集群调度来的tasks 启动一个内部的分布式数据存储系统 默认生成一个自签名的CA证书 生成一个tokens,为后面的worker和manager加入到该swarm 创建一个名为ingress的overlay网络,对外暴露swarm上的服务 manager node使用advertise地址来接受其他node访问Swarmkit API and overlay networking的请求,其他在swarm集群中的node,必须可以访问manager的advertise地址 ,如果你不指定advertise地址,docker会自动检查系统是否有一个单ip地址,如果有,则监听在该地址的2377端口。如果该系统有多个ip地址,你必须通过--advertise-addr来指定一个地址。 新的node需要一个token才能加入现有swarm集群,worker node使用的token不同于manager node使用的token,node只有使用join-token才能加入swarm,当Rotating join token的时候,是不会影响已经加入swarm集群的node的,rotation token可以确保老的token不能被所有的新node使用来加入swarm集群。 下面是swarm的一些关键点: 一个swarm包含了多个运行在swarm mode下的docker host,分别由manager和workers组成。manager来管理成员和授权,worker来运行swarm service。一个docker host可以是一个manager,也可以是一个worker,或者即是manager也是worker。还有一个大的优势是,如果swarm service中的容器是standalone模式的,你可以在修改service的配置后(networks、volumes) 不用重启service。docker会自动处理这些。 当一个docker host运行在swarm模式,你照样可以运行standalone模式的容器,但是swarm只能管理swarm service。 node 一个docer engine就是一个node,当你需要部署应用到swarm的时候,需要在manager node上提交部署作业,manager node会派遣task到worker node上。manager node也有编排功能。worker nodes接收并执行task。 service 一个service是定义好的在worker node上执行的task,swarm系统是一个中心结构的系统,当你定义好一个service的时候,你需要制定使用的镜像以及在镜像里面执行的命令。 在replicated services模式下,swarm manager分配定义好的replica task的副本数量的task在worker node上 在global services模式下,swarm service只运行一个task在worker node上 tasks 一个task包括一个docker容器和在容器里面运行的命令。task会被swarm自动调度。manager分配task到worker上。一旦task被分配到一个node上,该task就不能移动到其他node上了,除非该node fail。 Load balancing swarm使用 ingress load balancing,swarm manager可以设置一个PublishedPort给service,如果不指定PublishedPort,则是在30000-32767这个范围内自动选择。外部的请求,例如LB,可以通过PublishedPort来访问服务,但是这个LB的服务必须在node集群上,swarm集群中的所有节点都会连接到正在运行的service上,而不论该node上是不是有运行该service服务。在swarm内部有一个DNS,可以自动的分片在swarm中每个service的entry,swarm manager使用内部LB来分发请求到集群内部的service上
来源:OSCHINA
发布时间:2018-07-05 16:34:00
摘要: 融之家技术团队从2015年截止到目前累计经历了4次演进(单体应用、多实例部署、半微服务、微服务),让平台能更懂用户,更理解用户的需求,把合适的人匹配到合适的产品。 前言 本文章是根据潘志伟老师在上海Dubbo沙龙的演讲稿进行整理,意在为大家展示最真实、最一手的沙龙技术干货。 1、作者介绍 潘志伟(微信号panzw008),现任上海融之家首席架构师,十余年互联网架构经验 ,精通Microservice Architecture ,Hadoop拥有亿级用户平台架构经验 万级并发的API网关经验。 2、上海融之家 上海融之家金融信息服务有限公司作为消费金融领域领先的信息技术服务提供商,打造了国内第一款互联网贷款搜索平台,在短短2年内,用户数从0发展到3000W+,累计撮合借款金额近150亿。 面对如此快速的发展,原有的技术架构很难支撑越来越复杂的业务场景,在系统可用性以及稳定性方面以及快速迭代方面,都给融之家技术团队带来了很大的压力。因此,如何针对当前需求,选择合适的技术架构,保证架构平滑演进。融之家技术团队从2015年截止到目前累计经历了4次演进(单体应用、多实例部署、半微服务、微服务),让平台能更懂用户,更理解用户的需求,把合适的人匹配到合适的产品。 一、单体应用 创业初期,融之家初始创业团队在进行架构选型时,主要围绕以下2点进行考虑: 1、研发资源有限,研发人力有限、技术水平有限,需要选择一个易维护、简单、方便部署的技术架构; 2、产品需要快速研发上线,并能够满足快速迭代要求; 基于以上2点的考虑,创业期平台架构和部署方式非常简单,采用最通用的Spring MVC+mybatis+MySQL架构,使用一台ECS和一台RDS部署线上环境。 这种基础架构为业务快速上线奠定了坚实的基础,App上线后的效果远超我们当初的预期,业务进入快速增长期,但简单平台架构是也带来了很多问题。 二、多实例部署 由于业务高速增长,迭代需求非常频发,但是人力资源有限,根本不可能停下来重新梳理架构,但是又必须解决目前平台架构发版后暂停服务等问题,我们选择了在维护现有系统的基础上增加多实例部署的方式来解决业务问题。 引入Nginx做反向代理,用户Session信息写入Redis,通过Redis实现多实例之间的session共享。多实例部署方式帮助我们暂时解决了问题,这种架构方式也持续了很长时间。在这段时间内我们的技术主要是做功能的迭代,更新频率非常高。值得庆幸的是付出后有很大的回报,用户量增加非常快,交易量也有很大的提升。但随之而来的新问题又出现了,由于业务之间的共享都是依赖DB,导致平台里面存在大量重复的代码,代码之间耦合非常严重,线上的Bug频发、测试回归量巨大,每次迭代上线都没有办法完成回归。 三、“半”微服务 针对线上的频发的故障以及越来越复杂的业务需求,技术团队开始考虑重构系统,考虑引入微服务,微服务的降低系统复杂度、可独立部署、容错,可扩展的优点深深吸引了我们。希望通过服务的方式来隔离不同的业务,业务之间的依赖通过接口方式执行。在微服务框架的选型中,我们比对了Dubbo和Spring Cloud,经过技术内部多次讨论最后选型Dubbo 2.5.3版本。经过重构后的业务系统如下: 四、微服务 服务化后解决了代码耦合问题,也提升了线上产品稳定性。但是每个人编写的代码风格不一致,SQL水平不一致,有些人甚至在服务层做了多表联合查询,这给后续的分库分表埋下了隐患。为了统一代码风格,加速系统的重构,技术团队结合业务现在以及同行的经验,开发了一套微服务代码工具。 同时,重新梳理了微服务组件名称以及调用的流程。接口聚合层统一命名为back层,并处理协议转化(http->Dubbo),原子服务层统一命名为basic层,每个原子服务单独连接一台数据库。 对于每个业务进行重新梳理以及服务边界划分,引入HBase、Hive、ES、HDFS等存储模引擎做数据存储,重构后的业务结构图更清晰。 五、经验分享 1、预发布环境和生产环境兼容 目前业界比较通用的开发流程为开发环境、测试环境、预发布环境、生产环境。开发环境由开发人员维护,测试环境则有测试人员维护、预发布和生产环境则有运维人员维护。但是如果预发布环境和生产环境完全一致则浪费太多机器,但是预发布环境又是缺一不可的。因此引入group分组的概念,把需要验证的basic服务和预发布的back层所引入的服务配置在同一个组,则有效的解决了预发布和生产环境一致的问题。 2、服务权限控制 平台规模越来越大,参与开发的人员也越来越多,此刻权限问题尤其重要。对于用户层面的权限控制在back层面已经完成,但是对于内部核心服务之间的RPC调用也需要权限控制的需求。但是目前Dubbo对于权限这款的控制相对比较弱,通过了解业务方的需求后,基于Filter机制实现了一套RPC调用的权限认证。 支持如下授权:  按Application授权  根据IP地址授权  基于时间范围授权  基于方法名授权  非授权业务方试图调用服务则会触发告警 3、线程隔离 为了做到千人千面的推荐场景,在我们的App“借钱”列表中会调用后台几十个服务,而且会根据用户的行为实时调整排序逻辑。我们对于聚合后的响应时间也有明确约定要求<=1秒。为满足业务方 需求,重新梳理了业务调用逻辑以及依赖关系,改掉了之前串行调用方式,把能并行调用的服务的全部并行调用。设置ExecutorService来并行化调用,通过future来获取结果,同时设置了future.get 的超时时间。 然后由于依赖的后台服务过多,有些服务响应不及时,在高并发的场景下业务聚合层(back)的tomcat线程池爆满,拖垮整个服务,引起平台雪崩。技术团队引入Hystrix利用线程池隔离的方式来规避因某个服务响应慢而拖垮整个平台。为了降低现在代码改动量,基于hystrix做了自定义annotation,只要使用自定义的注解并设置响应的参数即可完成线程池的隔离。 4、熔断机制 我们希望能在配置中心手动触发熔断以及达到熔断触发值后能立即熔断且主动报警,如果直接使用hystrix提供的@HystrixCommand注解不能实现手动触发机制。对于熔断的一些指标如错误率、时间窗口、主动告警等做了个性化设置。基于上述的需求通过注解方式实现了@JdqHystrixCommand注解。只需要在需要熔断的方式上增加一句注解即可。 5、Mock平台 在开发、测试过程中经常出现这样的场景,前后端接口协议已经定义,但是后端依赖的很多服务,其中部分服务还没有提供,为了不影响开发进度,需要mock一些数据。测试人员需要模拟一次支付成功、注册失败、5秒延时返回结果,服务异常等等场景。需要能方便模拟,而且不需要研发人员修改任何代码。基于Dubbo的Filter机制实现了一套Mock平台,JDQMockFilter会在Consumer端以及Provider端执行。JDQMockFilter拿到请求后会先调用Mock平台查询是否有Mock服务。 6、监控 服务拆分后出现大量的服务组件,必须要时刻了微服务运行状态, Dubbo自带的简易监控中心不能满足我们监控需求。所以基于Dubbo的MonitorService自研了一套监控平台,实时收集微服务运行期间所产生的成功率、失败率、平均耗时、最大耗时、并发量、数据传输排行等。对于服务的下线,耗时过长都会触发报警。 7、服务框架预览 经过4次的架构演变,平台的稳定性、吞吐量、并发量都有非常大的提升,整个RPC框架也重新定义了,增加了权限平台,mock平台,监控平台。 六、总结 微服务架构可以更好的进行业务解耦,具备更好的扩展性以及独立性,可以提高研发团队间的并行化研发速度,提升效率、提高模块复用性,具备高可用、高并发特性。但微服务架构对服务治理的能力要求比较高,维护成本也会比单体应用高。Dubbo 出生于阿里系,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;只需要通过 Spring 配置的方式即可完成服务化,对于应用无入侵。我们借助Dubbo完成了微服务重构,目前用户数以及接口调用量都在不断提升。 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-07-05 16:33:00
很多人都有一个建站的心,但是由于没有相关的技能,导致最后不了了之。云计算,让一切变得简单起来,零基础也能很快搭建出自己的网站,满足你的心愿。 建站总体来说分为如下几步: 1.开发网站程序 2.上传到云服务器 3.填充内容 4.域名备案解析 然后就可以把自己的网站分享给朋友了,建站就是这么简单! 如果网站规模大了,应该如何在保证低成本的前提下,承担大的访问量,以及提升网站访问速度呢?这就需要结合云数据库、云存储等,来实现网站的高可用。 6节课+3个在线实验,让你快速掌握云上建站。课程报名: https://edu.aliyun.com/workshop/6/course/1043 课程设置: 第1期: 掌握云服务器基本操作(含在线实验) 掌握云服务器基本操作,是云上建站的第一步。 第2期: 安装LNMP环境+搭建WordPress+域名配置(含在线实验) LNMP是最常见的网站运行环境,本课程带你安装LNMP环境,并搭建动态网站。 第3期: 数据迁移至云数据库,提升数据可靠性 从自建数据库迁移到云数据库,提升数据可靠性与安全性。 第4期: 使用云存储和CDN,降低成本并提升速度 网站规模越来越大,如何做好网站优化呢?那么就来好好学习这节课程吧! 第5期: 网站优化配置与安全防护 自定义网站功能和布局,让它符合我的需求;为网站进行安全加固,防止被攻击和篡改。 第6期: 建站举一反三:快速搭建论坛网站(含在线实验) 学会了WordPress建站,那么如何搭建一个论坛网站呢?本课程带你快速掌握。 讲师介绍: 缪政辉,阿里云MVP,云栖社区版主,在网站建设开发和云计算领域有多年经验,致力于以场景化的方式让云计算,用更加通俗易懂的方式让更多人体验云计算,让云端的计算更质朴的落地。
来源:OSCHINA
发布时间:2018-07-05 15:57:00
本文作者为美国著名分析师James Governor。James Governor是RedMonk的首席分析师和创始人。他负责领导企业应用程序领域的相关分析报道,为客户提供应用程序开发、集成中间件和系统管理等问题的分析和建议。James Governor有十多年的从业经验,他的分析与观点常被美国和欧洲的媒体引用,他还曾任BBC等媒体机构的特邀行业专家。 Rancher Labs 于6月28日在旧金山举办了分析者大会。Rancher Labs在美国已拥有200多家付费企业客户,考虑Rancher产品的下载使用量,以及Rancher Labs只是一个成立短短4年的初创公司,这个付费客户数已经非常可观。此次分析者大会上,有13位客户代表进行了发言分享。整场分享没有在市场宣传上做大动作,而是密切关注于技术层面的干货输出。每一位发言人都提供了很有意思的技术见解。 K8S平台的强大功能VS简易性 Rancher Labs CEO及联合创始人梁胜博士首先针对“平台的强大功能性VS.简易性”之间的取舍及对比展开了完整有力的讨论 。虽说AWS在推出伊始也很简单,但不可否认,AWS如今已变成了一个完整、功能强大的平台,拥有一系列先进功能来与传统企业供应商(如VMware)相抗衡。 正因如此,那些想使用开源产品(如原生Kubernetes平台)来避免技术锁定的用户,正面临“开源开放VS.方便强大”这个进退两难、难以抉择的困境。通常情况下,用户会选择“便捷”这一属性,这也是AWS如今能垄断市场的原因之一。 “做一个管理平台,仅仅是‘能在多云环境下均可使用’,这一特性是远远不够的,用户需要的是一个比让他们自己直接使用多云更优的解决方案。”梁胜博士表示,“为了推动用户对多种云的使用,市场期待比AWS更优的产品。” 这正是对Rancher以及业里其他玩家的挑战。只提供可移植性是不足够的——跨平台体验需要更好的表现方式。 当下市场广泛接受的一个观点是,我们需要云基础设施以及微服务更多地为用户服务,而不是要用户小心翼翼地去维护基础设施——粗暴点说,即虚拟机和容器需要是短暂且可抛弃的。在持续部署和应用镜像扩容的年代,服务是很难持续的。不断修修补补打补丁的方式,终将会被不可变基础架构取代。 最初当Docker腾飞时,Rancher Labs结合其自身一贯的简易、灵活的理念,创建了自己的容器编排和管理平台,称之为Cattle。Cattle能在开发人员的笔记本电脑上构建及管理Docker镜像,这一特性帮助Rancher 1.6赢得了业界的“易于部署和管理”的赞誉。 但在2017年,Kubernetes逐步赢得了容器编排工具之战,成为了标准的容器服务编排环境。Rancher Labs极具前瞻性地对Rancher产品做了重大升级转向,新推出的Rancher 2.0延续了Cattle一贯的简洁易用的特性,但成为了完全基于Kubernetes的平台。Rancher的这一决策也充分证明了我们前文所说的“灵活性”的理念。虽说不少客户认为 Cattle比Docker Swarm、Apache Mesos或Kubernetes更简单、更易于使用、甚至可能更适合他们的需求,但在2.0产品上他们不得不放弃对Cattle的使用。Rancher并不是唯一作出这样决策的公司 ——例如,Docker公司原本拥有自己的编排工具Swarm,但也在不久后宣布拥抱Kubernetes;Mesosphere现在也支持DC / OS上的Kubernetes。 Kubernetes不是哪家公司的竞争对手,当下情况是,业界各公司正处于Kubernetes这一环境中在进行竞争。 Rancher的此次大会可能是最具说服力、最具参考价值的,因为客户的紧张感暴露无遗。客户在一定程度产生了认识失调。一方面他们想继续使用Rancher的Cattle编排调度工具,另一方面他们意识到Kubernetes的势头不可抵挡。同时对于Rancher来说,从研发团队的角度看,标准化Kubernetes总是比支持多个第三方协调引擎更容易。 因此,对于Rancher 2.0而言,它的工作主要是通过CLI、UI、Compose等,来为运行在Kubernetes pod上的容器提供Rancher UX和API。原生支持Kubernetes,意味着对于那些想要使用Kubectl、Helm chart的公司而言,所有常见的Kubernetes工具都可以用了。 Rancher还计划通过Prometheus(用于监控和指标)以及RBAC(基于角色的访问控制)等工具提供更好的集成。 Rancher拥有自己的身份验证模型,并支持SAML、LDAP和Microsoft Azure Active Directory。用户可以设置警报和阈值——例如,如果etcd内存消耗超过70%,它会通过Slack通知团队。 Rancher首席架构师Darren Shepherd对功能性与简易性的理解略有不同,他在大会上表示Rancher正在开发的一个名为Rio的新项目——基于Kubernetes,拥有用户熟悉的、简单的Docker 1.11.x 风格的UX,拥有端到端的服务,包括构建、运行时、日志、监控与无服务器架构。 我在大会上询问了Rancher Labs团队如何达到产品、服务和技术支持间的平衡。 Rancher联合创始人兼销售副总裁Shannon Williams说:“客户使用Kubernetes之后,我们需要为客户提供的服务大部分都是培训。 然而AWS、VMware它们都不需要这样做。 如果产品易于使用,技术浪潮中并不需要这么多培训”。 客户对于K8S与Rancher的想法 客户对此说了什么?这里有一系列的观点。 Sling TV目前正在VMware上运行容器,并希望通过采用原生的Kubernetes避免未来技术锁定的风险。 它计划将容器从VMware迁移到AWS,因此可移植性是他们非常看重的特性。 正因如此,他们选择了可以纳管兼容不同基础架构容器服务的Rancher。 Toyota Connected是一个很有趣的案例,一部分原因是因为与其他客户不同,丰田直接选用Rancher 2.0,而不是1.6或更早的版本。 也就是说,它因为选择Kubernetes而选择了Rancher,而不是因为摒弃Kubernetes而选择了Rancher。 Toyota Connected高级开发与运维工程师Ross Edmond说:“Kubernetes并不完美,但我们坚信它有着非凡的持久力、未来发展会越来越好,一是因为它的功能非常强大,二是因为它可以让用户进行很多拓展,从而进行长期的、可持续性的探索。” 丰田公司所有出售的凯美瑞车型的“主机(head unit)”(也就是仪表板中带有无线功能、蓝牙、网络等的部分)都将运行在Kubernetes上。 丰田公司希望通过Kubernetes的灵活性加快公司的软件开发速度,并使用各种堆栈(例如,丰田用Java和Elixir编写软件,而这需要Erlang虚拟机)。 丰田凯美瑞的远程信息中包含超过100个微服务。在启动时,该服务需要能够支持1500万辆汽车。HA配置中的集群目前为20到30个节点。Kubernetes这一最初是用于管理Google服务器群的开源软件,如今已经开始服务于汽车仪表盘,这真的让人感到难以置信。 Edmond继续说:“Rancher Kubernetes Engine(RKE)不再需要用户‘自带容器’。它与底层基础设施并无绑定。使用RKE大大降低了我们使用其他云的启动成本。” 国家能源研究科学计算中心(NERSC)是美国能源部的一部分,也是另一个精彩的案例——实现了在Cray超级计算机上运行Docker。它使用容器进行计算工作——一个NERSC开源项目Shifter将Docker镜像随时转换为Cray超级计算环境中的非特权用户——那有9000个节点。 NERSC还以更传统的方式为应用程序开发工作流程提供容器。它选择Rancher进行身份验证、CLI、管理工具和策略实施。 总而言之,与容器生态系统中的其他参与者一样,Rancher现在专注于优化改善Kubernetes的易用性 。Kubernetes将成为未来几年的基础设施的重要角色。这次活动让我深刻地认同 Rancher在这方面有很好的基础,而这势必会在将来帮其赢得更多的新客户。 英文原文: https://redmonk.com/jgovernor/2018/06/28/rancher-labs-treating-cattle-like-cattle/
来源:OSCHINA
发布时间:2018-07-05 10:48:00
摘要: 当你观看视频如遇网络不好的情况,就会出现卡顿或系统提示切换成标清或流畅的画质,这个时候你会发现视频的清析度降低了。高清意味着高分辨以及需要更大的带宽来支撑,高清和宽带是一对矛盾体。这届优酷世界杯直播受到一致好评的关键,阿里云“窄带高清2.0”发挥了重大的作用。 写在前面 2018年俄罗斯世界杯比赛正在如火如荼进行中,互联网视频平台的入局,新媒体直播赛事的火爆,让本届世界杯也有了一个新标签:掌上世界杯。这意味着,用户可以更加随心所欲的“躺着看球”。 半数球迷选择优酷 超6成认为高清且流畅 根据流媒体网调查数据显示,今年使用手机看世界杯的用户中,超过50%的用户选择优酷。而在新媒体平台加入直播的情况下,大部分的用户对直播的清晰度和流畅度表示满意。 另外一个数据显示,光酷喵在世界杯期间就有超过800万的用户通过投屏智能电视的方式观看世界杯,把客厅变成了世界杯的主场。只有真正的高清画质,才能扛住手机超清屏以及电视超大屏的双重考验。 当你观看视频如遇网络不好的情况,就会出现卡顿或系统提示切换成标清或流畅的画质,这个时候你会发现视频的清析度降低了。高清意味着高分辨以及需要更大的带宽来支撑,高清和宽带是一对矛盾体。这届优酷世界杯直播受到一致好评的关键,阿里云“窄带高清2.0”发挥了重大的作用。 那窄带高清究竟是什么呢? 带宽成本是视频服务中非常重的基础设施成本,如何在保证视频质量的前提下降低成本是整个链路中至关重要的一环。所以,在视频服务中,视频的编码和解码是非常重要的技术。 业内的转码技术从MPEG2,到H.264,到H.265大概是下图的技术发展曲线,每隔十年的时间,视频的压缩率会提升一倍左右,平均下来,每年行业视频压缩率能提升只有不到7%。这种客观发展规律之下,视频行业内的从业者给对手造成压倒性的竞争优势已经变得非常困难。 传统的视频编码以信号的损失量最小作为编码的目标,力求输出视频与输入视频的差值最小,但实际上,同样的编码损耗,在人眼看起来的清晰度可能相差很大,因为人眼对不同画面位置的敏感程度是不一样的。窄带高清是一套以人眼主观感受最优为基准的视频编码技术,通过对直播内容的智能分析,根据对人眼敏感度进行动态处理与编码,以达到最佳的主观清晰度效果。 窄带高清2.0背后有三套视觉模型 保真度和主观感受的关系模型 当视频的保真度越来越高时,人眼逐渐就没有感受了,所以编码时卡在失真度并没有很大变化的临界点上,就可以适当节省带宽。下图为保真度与主观感受模型关系图。 分辨率和码率的关系模型 为了保证在某个网络条件下能够流畅播放,视频的码率需要有一个上限,在这个上限的条件内,如果分辨率选择过高,会导致分配给每个像素的比特太少,导致视频模糊,如果分辨率选择过低,虽然能够描述清楚每个像素,但是需要依赖播放器做插值放大,视频也会模糊。窄带高清结合了大量视频样本的分析,在一定的码率设定下,会根据视频的内容智能选择最合适的分辨率,达到最好的主观视觉效果。 视觉敏感度模型 窄带高清会将视频内容分为人眼容易关注的和人眼容易忽视的部分,并对这些部分做不同的处理。对于人眼容易关注的部分,除了人眼聚焦的区域外,人眼还关注规则的纹理,例如球场中的禁区线,球员的轮廓,这是我们一定要保护的区域,我们会在这些区域做一些调整优化,让它更加突出,使画面更有张力。对于人眼容易忽视的部分,例如脱焦区域就,我们可以把这块的处理省掉,同时,我们也可以去掉一些没有聚集效应的小细节,以此省掉带宽。例如,球场中的观众席,广告牌的背景就属于人眼脱焦的区域或没有聚集效应的小细节。除此之外,人眼还会非常厌恶毛刺、马赛克,持续的闪动,我们将这些细节处理得更平缓、清晰,能提升画面整体观感。 下图为窄带高清对人眼聚焦区域的增强,图中为梅西准备发定位球的场景,画面的焦点集中在梅西的脸上,在没有经过窄带高清时(左图),会发现梅西的脸上很多细节被丢失了,看到的画面比较平滑,有点像打过一层粉,而经过窄带高清的编码(右图),脸上的细节被完整的保留下来,并进行了适当的强化,使得画面有很强的立体感。 窄带高清世界杯升级版 在引入了以上的三个模型以后,在这次世界杯直播中,窄带高清还针对足球直播场景,基于机器学习优化了特有的编码策略,比如足球、草地、球员分别采用特别编码策略进行优化,大幅提升了比赛画面的层次感和通透性。 在足球比赛中,画面经常会在不同场景中切换,如何在场景切换中保持清晰度需要有精巧的码率控制策略。一方面,视频码率不能恒定不变,如果恒定不变,突然的场景切换会导致分配给运动场景的码率过小,导致画面模糊。另一方面,视频码率不能大幅度波动,如果大幅度波动,会容易导致用户卡顿,也会导致CDN带宽发生剧烈波动,这样的剧烈波动对CDN调度将会是巨大的挑战。窄带高清分析视频画面的运动剧烈程度,结合对视频长时间码率分配的统计学习与实时视频运动复杂度,在有限的播放器缓冲范围内进行码率腾挪,可以在保证指定带宽下播放流畅的同时尽可能地提高主观清晰度。 下图为另一个世界杯转播公司画面的(左)与优酷(右)在1080P和480P的画面对比,当切换到这个细节丰富,且运动剧烈的角球争抢画面时,使用窄带高清和非窄带高清的效果相差非常巨大。在没有使用窄带高清时,会出现对该场景的码率分配严重不足,导致非常糟糕的用户体验。 下图为窄带高清在不同码率下的与x264,x265的评测对比,可以看到,无论是主观评测还是VMAF评分,窄带高清与普通编码有一代编码器的差距,在相同清晰度下可以节约30%带宽。 写在最后 阿里云作为强有力的技术作为支撑,和优酷一起解决了体育赛事卡顿、清晰度低的用户痛点,以高清、流畅、零延时的极致观看体验俘获大批球迷。当然,除了窄带高清技术之外,阿里视频云也拥有众多行业领先技术,目前已经是国内视频服务体量最大的云计算公司。从阿里云视频云诞生以来,一直在致力于用自身的技术,去创造一些行业里独有的东西。阿里云将通过阿里集团多年的技术沉淀,构建不一样的视频云服务,让客户也变得与众不同。 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-07-04 16:38:00
摘要: 今天我分享的内容分成三个部分: 第一部分是“大前端时代前端监控新的变化”, 讲述这些年来,前端监控一些新的视角以及最前沿的一些思考。 第二部分"前端监控的最佳实践", 从使用的角度出发,介绍前端监控系统的各种使用姿势 最后是“阿里云ARMS前端监控系统架构”, 简单地剖析下,阿里云前端监控系统是怎么实现的。 本文来自阿里云前端监控团队,转载请注明出处 本文为2018年6月21日,在北京举办的GMTC(全球大前端技术大会),下午性能与监控专场,由阿里云前端监控团队前端技术专家彭伟春带来的演讲稿,现场反馈效果非常好,地上都坐了三圈,很多人反馈根本无法挤进去。先上现场照。 正文从这里开始~ 大家下午好,今天我给大家带来的主题是《大前端时代前端监控的最佳实践》。 先做一个自我介绍,我叫彭伟春,英文名是Holden, 阿里花名是六猴, 大家都叫我猴哥。是阿里开源同构框架beidou的作者,目前是阿里云前端系统技术负责人。 今天我分享的内容分成三个部分: 第一部分是“大前端时代前端监控新的变化”, 讲述这些年来,前端监控一些新的视角以及最前沿的一些思考。 第二部分"前端监控的最佳实践", 从使用的角度出发,介绍前端监控系统的各种使用姿势。 最后是“阿里云ARMS前端监控系统架构”, 简单地剖析下,阿里云前端监控系统是怎么实现的。 先进入我们第一个环节 大前端时代前端监控新的变化。 要了解前端监控新的变化,还得先看看前端这些年发生了哪些变化: 首先是Gmail的横空出世,开启了SPA的时代 Backbone/Angular等框架带来了MVVM模式的同时,也把JS从脚本语言提升到了工程语言 React Native/Weex把移动端开发从Hybrid模式进化到了跨端开发模式 Node.js问世为前端带来了更多的可能性 前端这些年发生了翻天覆地的变化,又会给监控带来什么呢?让我们思考下以下几个问题: 传统监控模式能否适用于新的技术?比如PV统计 SPA模式下首屏如何计算? 跨端开发给监控带来什么什么挑战? 前端监控的上报模式在Node.js端是否合理? 接下来我和大家一起探讨其中的一两项 早些年,SPA如此盛行,我们也在业务中做了尝试,体验是大幅提升了,可业务方却吐槽PV下降了。 那到底是什么导致了PV下降了呢?在后端直出时代,我们每一次的交互,都是向后端请求一个新的页面,PV自然就高,改成SPA模式之后,大量的页面请求变成了页内路由,或者说是页内转场。那如何解呢?这难不倒我们,大部分框架路由都是基于哈希实现的,我们只要侦听hash改变,每次改变上报一次PV就好了。也有少量的路由并不是基于哈希实现的,比如angular, 这时候就需要轻量级地hack pushState和replaceState。 这样就完美了吗? 我们再思考下以下几个案例 某新闻类的网站,每次看完之后,都会下拉刷新,加载新的内容,这个时候是算一次PV还是多次? 天猫商品列表页,看完一屏之后,向上滚动会再加载新的一屏,PV该算一次还是多次? 阿里云邮后台一直开着,每周上百次查看,是算一个PV还是每次查看都计算一次? 未关闭的浏览器tab几小时之后再次浏览,该不该再计一次PV? 查找信息时,浏览器Tab之间快速切换,切换过程中要不要计一次PV? 其实还有很多其它层出不穷的场景,具体该如何去统计PV留给大家去思考, 不再展开。 接下来我们探讨一个大家最感兴趣的话题: 性能。先看一组我们的统计数据,淘宝旺铺页面点击率随加载时间变长从85%的点击率逐步降低到了82%,别小看这3%,在阿里这么大的体量下,3%意味着巨大的商业价值,那站在前端监控的角度,首屏是如何统计出来的呢? 回到那个刀耕火种的年代,那时候要什么没什么,都是自己动手丰衣足食。这就是手动打点阶段: 手动打点,分别在页头和首屏dom节点处new Date()打点,计算差值,作为首屏时间,再加上setTimeout(new Date(), 0)标记首屏可交互时间。 随着前端的飞速发展,手工打点的模式早已满足不了需求了。为了帮助开发人员更好地衡量和改进web性能,W3C性能小组引入了 Navigation Timing API 帮我们自动,精准的实现了性能测试的打点问题,大致地过一下,性能API里面包含了【卸载上一个页面】【重定向】【应用缓存】【DNS域名解析】【TCP连接】【请求页面】【响应】【页面处理】最后触发load事件,通常我们把domContentLoaded作为首屏时间。Chrome最早支持,IE跟进。 在很长一段时间里,我们都享受着performance API带来的便利, 但随着SPA模式的盛行,我们再回过头来看看W3C标准是否足够了。先来看一个案例,这是阿里云某产品的管理后台。整个加载过程分成三个部分,1. 加载初始的空壳页面 2.加载JS资源并异步请求数据 3. 前端渲染中间的主体部分。按照W3C标准取值首屏时间应该是1106ms, 而实际的首屏在1976ms,也就是完成异步取数据后渲染完页面的时间点。为什么会相差如此大呢?实际上SPA的盛行让W3C标准失去了原来的意义。 针对这种情况Google lighthouse提出了FMP的概念,first meaning paint, 也就是主要内容可见时间,那什么是主要内容? 每个人得出的结论可能会不一样。 先做一个猜想:主要内容 = 页面渲染过中元素增量最大的点。 先通过飞猪案例做一次验证。 猜想成立。 再通过手淘案例做一次验证。 猜想不成立。 那到底是什么原因导致我们的猜想不成立? 首先是元素是否可见, 不可见的元素对用户的影响基本为0。 其次是每个元素对页面的影响是否等效?由此引出权重,不同的元素采用不同的权重计算影响。阿里云前端监控 根据上面的修正因子。我们重新设计了一遍算法, 计算每次变化的得分,一起来看看,算法是如何实现的? 如图所示分为三个步骤 侦听页面元素的变化; 遍历每次新增的元素,并计算这些元素的得分总; 如果元素可见,得分为 1 * weight(权重), 如果元素不可见,得分为0; 如果每次都去遍历新增元素并计算是否可见是非常消耗性能的。实际上采用的是深度优先算法,如果子元素可见,那父元素可见,不再计算。 同样的,如果最后一个元素可见,那前面的兄弟元素也可见。通过深度优先算法,性能有了大幅的提升。 再拿之前的手淘案例来验证一遍。 经过改良之后,第三屏主要内容的得分是最高的,符合预期。 那么接下来首屏统计又会发生什么样的变化呢?其实统计首屏时间本身就是浏览器的职责,交由浏览器来处理是最好的。目前W3C关于首屏统计已经进入了提议阶段,坐等W3C再次标准化。大家可以在github上看到最新进。 限于篇幅,前端监控其它新的变化不再展开。讲了这么多前端监控的新变化,那什么才是打开前端监控最最正确地姿势呢? 由此进入我们的第二个环节,“前端监控的最佳实践”。 我用一个表达式“要是什么什么就好了”来总结。我经常会想【要是天上能掉钱就好了】,【要是有个机器人帮我写代码就好了】。同样的,每次发版之后都是提醒吊胆的,不知道用户到底能不能正常使用。(这时候你就会想)要是能有双眼睛帮我盯着系统就好了;每次出错,都是用户投诉反馈问题,实际等到用户主动反馈问题,影响面已经非常大了: (这时候你就会想)要是能在第一时间发现错误就好了; 还真有这样的案例,前年双十一凌晨值班,突然收到邮件和短信告警,于是点开了详情。 发现在接口成功率趋势图中,接口请求量大幅上升,伴随着成功率急剧下降,再查看错误信息聚合模块,发现频率最高的错误信息是【交易规则冲突】,深度排查之后,最终找出了原因,是运营配置的双十一优惠规则和平时优惠规则产生了冲突,导致下单失败。最后凌晨4点申请了紧急发布修复了冲突,解除告警。 由此可以得出最佳实践之一:主动监控。当然主动监控的内容不仅局限于API成功率,也包括JS错误率等。稍微总结下流程:先是配置告警规则; 然后就可以放心大胆地睡觉了,如有任何风吹草动,系统马上会通知到我们,再通过错误聚类模块,精准地定位问题。再手起刀落,bug修复完成。 再回到我们的【要是什么什么就好了】,在做性能优化的时候,有时候明明整体性能已经不错了,可偏偏有少量用户觉得很慢:(这时候你就会想)要是能知道慢速用户发生了什么就好了。 这时候我们就需要用到【性能样本分布】,打开页面性能页面,查看0 -60秒之间每个区间的性能样本分布情况,从分布图中可以看出来大部分用户加载时间都在2秒以内,极少数部分用户的页面时间在10秒左右的。 拖动下面的滑块,缩小时间范围到10S左右,这时候系统就会筛选出10秒左右的慢会话。 点击展开某次慢会话,不仅可以看到这次慢会话的基本信息,比如网络类型等,还可以看到完整的资源加载瀑布图,可以清晰地看出来,具体是什么资源导致整个会话变慢。由此我们又可以得出最佳实践之二:慢会话追踪 再回到我们的【要是什么什么就好了】,有时候用户提交了一条反馈,某某功能出错用不了,这时候你又不知道用户端到底报了什么错,是不是又得打电话给用户,还得手把手教用户如何通过浏览器开发者工具把错误截图下来发你。我哩个去,用户这个时候很可能因为系统太烂了,已经不堪其辱,早就把页面关了并且发誓再也不用这破系统。(这时候你就会想)要是能知道用户报了什么错就好了。 别怕,打开阿里云前端监控的【访问明细】搜索用户ID,直接可以看到该用户在访问过程中,到底报了什么错。 有时候拿到了用户报错时的基本信息,也知道用户报了什么错,但是在自己电脑上调试的时候,无论如何也复现不了,这个时候是不是又得去和用户沟通,让用户描述重现路径,实际上用户可能自己都忘了具体怎么做才能重现错误。(这时候我们就会想)要是能重现用户行为就好了。 【视频演示】我们现场来模拟一次用户出错还原,左边是用户实际操作的屏幕,为了更好地展示效果,我把用户行为实时地展示在右边的屏幕上: 第一步: 模拟用户在淘宝页面上做出了一系列的操作, 鼠标移动、滚动页面,搜索等; 第二步:假设突然出现了某某错误,这时系统会把记录的用户行为存储到服务端; 第三步: 开发人员通过会话ID查询到出错行为,最终进行还原。大家可以看到左边屏幕不再操作,右边屏幕还原出了之前出错的所有行为。 大家一定在想这么炫酷的能力是如何实现的呢?接下来就为大家揭秘阿里云前端监控系统背后的技术架构。 就从大家最感兴趣的错误还原讲起,大家可能在猜测,是不是把整个页面录制成视频了。其实不是这样的,视频太大了,不可能出错了把一个视频发到服务端,这样是对用户资源的严重浪费。先看示意图(跟着箭头从左到右): 首先,每一次会话都有一个唯一的session ID,这是串联起所有行为的纽带。 其次,用户行为又分成两个部分,其一是用户的操作,比如鼠标滑动,点击,页面滚动等,其二是页面的变化。这两者我们都统称为用户行为,记录在同一个队列中。 一开始的时候,系统会记录下初始的页面作为第一帧,这是唯一的一次完整页面记录。 针对用户操作,我们会记录事件的类型,鼠标位置等关键信息,保存到队列中。 针对页面变动,我们会起一个mutationObserve侦听页面的改动,每次只记录改动的部分,保存到队列中。 无论是事件还是页面改动,都是对等的一帧,每一帧都会有当前时间,与上一帧间隔时间等基本信息用户还原。 一旦出错,SDK就把队列发送到监控系统,并清空当前队列。 还原端根据记录的行为队列,根据时间逐一播放出来。最终形成一个类似于视频的效果。 大家可能觉得还不过瘾,接下来为大家讲一下阿里云ARMS前端监控系统的整体架构。 首先从左到右分成三个域。分别是日志采集域,日志分析域和监控告警域。在日志采集域,客户端通过SDK将信息上报到Nginx服务器, 日志服务SLS在Nginx服务器上起一个agent,去把日志信息同步过去,日志到了SLS就相当于到了一个大的蓄水池。再通过实时计算引擎的计算,结果部分存储到HBase,另一部分结果回存到SLS日志服务用于搜索。 最终通过restful API向前端提供数据,前端渲染出数据dashboard. 是不是感觉很简单地样子,有句话叫做【看山跑死马】,山看起来就在眼前, 可就算骑马过去马都会累死。那就让我们一起来揭开它的神秘面纱吧。 接下来重点介绍跟前端同学工作密切相关的日志采集域,相比业界,我们的日志采集还是有很多可圈可点之处的。比如说: 静默采集: 只需要一行代码接入SDK就行了,所有的API请求、资源加载、JS错误、性能等都自动监控起来了。省去了繁琐的配置。 单元测试 + 自动化测试:前端监控的目的就是去监控前端的异常情况,不给页面带来新的异常这是我们的底线,对此,我们有完善的单元测试和自动化测试去保障SDK本身的质量。 (SDK出错隔离):但实际上任何系统都不能保证自己不会出错,那么万一SDK本身报错了,我们还有异常隔离机制,确保出错也不会影响业务的运行。 这些内容我都不详细展开,那接下来我重点讲一下,阿里云前端监控是如何突破局限优雅地上报日志 大家都知道,http徵求意見稿rfc2616规定浏览器对于一个域名,同时只能有 2 个连接。而PV、UV、ajax请求、JS逻辑错误、页面资源加载等等都会触发上报,同时2个连接明显不够用,可能会造成网络阻塞,上报延迟 后来在修正稿rfc7230中去掉了这个限制, 只规定了限制数量,但并未指定具体数字,浏览器也实际放宽了限制。比如Chrome是同时6个连接。 然而,一个请求独占一个连接,有时候6个连接也是不够用的 大家可能会想, 那既然规范都没有指定要限制多少条,那浏览器为什么还要限制6条呢?其实也是出于公平和安全考虑,如果不限制数量,理论上一个客户端就能占用大量服务器资源,甚至压垮服务器。 那如何突破限制呢?有一个绝招:就是升级到http2, 利用h2的多路复用特性。 一个连接上打开多个流,还可以双向数据传输,轻松突破6路并行限制。 思考一下:在http1时代的把资源散列在不同域名下还有效吗?实际上非但不能提升性能,反而会新增连接开销。 突破6路限制就够了吗?我们再来看看另一个很容易被忽略的部分:http头部损耗。 http请求中,每次请求都会包含一系列的请求头来描述请求的资源和特性等。而头部没经过任何压缩,每次请求都要占用200-800个字节,如果带上一个比较大的cookie,甚至会超过1K; 而我们实际的日志数据大小仅仅只有10 - 50字节,头部消耗占了90%以上; 另外,据Htpp Archive统计数据,平均每个页面上百个请求,越来越多的流量消耗在头部; 最致命的是,UserAgent等信息不会频繁变动,每次请求都传输是一种严重的浪费。 再次利用h2头部压缩。先来看看采用h1和h2的效果对比。 h1下请求大小295 字节, 而h2仅仅只有18 字节,大小只有区区16分之一,请求时间也从6ms降低到了4毫秒。 太神奇了,来快速地过一下http2头部压缩是如何实现的: 首先协议里预设了一个静态字典,用来表示常用的头部字段,比如图中,2就是 method get. 以前需要把完整的key-value对发过去,现在只需要把一个数字发过去,大小大幅缩小。 其次,客户端和服务端会共同维护一个动态表,动态表用来干啥呢?举个例子,比如useragent, 每个用户的useragent值是不一样的,没法放到静态表中去约定。但是对于同一个用户会话,useragent是不会改变,这样的值,就由客户端和服务端协商决定存入动态表,这样第一次传输过去之后,以后就只需要传入动态表中的一个编码就行了,图中的62和63就是这样的情况。连接中发送的请求越多,就越能丰富动态表中的值,越到后面,请求性能越好(佐证了域名散列的方式不可取)。 还有一类情况,值总是变来变去,也没法保存到动态表中。这时候,只能直接压缩了。在h2中采用的是Huffman压缩算法,能把数字或字符最短压缩到5个字节,最大压缩率是37.5%。 其实除了头部压缩外,还有很多办法减少体积,比如 采用http 204返回无响应体的response; 采用post请求合并多条日志,共用请求头; 错误调用堆栈中经常会出现很多的文件url,占了不少空间,可以考虑将他们抽取成一个变量; 时间关系,日志采集部分就到此为止。 接下来我们来看看一个监控系统最核心的部分:实时计算。 实时计算采用的是业界已经非常成熟的流计算,简单地过一下概念。 这是一张表示流计算的经典结构图,有两种组件,水龙头是spout,代表数据源, 闪电是bolt, 代表处理逻辑。这里面有两个很重要的特征。 其一是计算能力弹性,如果有更大的日志量流入,能够动态调度更多的算力来保障计算的实时性; 其二是反压。每个计算节点都可以根据自己的负载情况反压上一级的计算节点,从而实现计算任务的更合理地分配。 思考一下:如何在海量日志中实时取到限定条件的聚合数据?如图所示,我想实时拿到【模拟页面】在【广东省】【最近24小时】【访问速度】走势。 分析一下,如果需要画出这样的走势图,每个小时画一个点,需要取24个点的值,每个节点写个SQL把符合条件的数据求平均,如果数据量很小的时候,取24次数据勉强性能上勉强可以忍受。 但是如果作为一个SASS系统,监控系统会接入非常多的项目,每时每刻都有大量的数据上报。系统也会积累海量的数据。取一个节点需要多少时间呢?参考离线计算大概要15分钟, 24个节点,预估需要6个小时。这明显是不可接受的。那阿里云前端监控是如何做到实时拿数据的呢? 这就需要用到我们的大数据处理神器dataCube(数据立方),我们来剖析下数据立方是如何解决实时性的问题的。 如图所示: 拿浏览器、设备、地理区域三个维度为例,组成一个三维的数据立方。立方中的每个小格子代表一个聚合数据。 请看图中数字3所在的格子,3代表三维,也就是Vivo设备、chrome浏览器在北京地区的聚合量。 再看一个黄色切面上的数字2,黄色切面代表浏览器维度的聚合,也就是上海地区Vivo设备的聚合量,包括所有的浏览器。 再看最右下角的数字0代表0维,也就是所有的聚合量,包括所有的浏览器、所有的设备、所有的地区。 数据立方的秘密就是把所有格子的值都预先计算出来,下次要取值,直接取数据立方的某个值就好了,本质上是一种空间换时间的思路。 看一个我们实际的处理场景,元数据经过流计算之后,每个每分钟、每小时、每天都会产生一个数据立方。而这个数据立方多达90多维。回到之前的案例,如果我想限定若干个条件拿到24小时趋势图,我只需要24个数据立方中把指定位置的小格子取出来就行了。计算时间就能大幅压缩到秒级别。 原文链接
来源:OSCHINA
发布时间:2018-07-04 16:08:00
摘要: 阿里云专有宿主机为什么能够成为公共云上的专有资源池 过去几年,云服务深刻的改变了社会获取和使用计算能力的方式,云已经逐渐演变成水电一样的基础服务,越来越多用户逐步迁移上公有云,有很多客户从自有机房迁移上公有云都会遇到如下一些问题: 自带许可证场景(BYOL)上云 如果用户已经购买了按物理核数、VM个数或者Socket数授权的许可证,那么用户希望在公有云上继续使用这些许可证,并受许可条款的约束,籍此节省许可证费用。包括但不仅限于:Windows Server、SQL Server、Oracle等; 安全合规要求 如果用户的业务有合规性的要求,如金融类用户,希望物理服务器独占,满足严格的物理隔离性要求。与此同时用户也希望可以将实例部署在指定的物理服务器上,满足业务运行环境监管要求; 性能稳定性极度敏感场景 如果用户对服务器计算能力和计算环境的稳定要求都比一般业务高,如游戏类用户,希望独占物理机,进一步提升业务CPU、网络IO资源环境的稳定性,确保游戏稳定可靠地运行; 自主部署的场景 用户希望可以定义一些规则在公有云上ECS实例的自动化部署,也可以实现指定物理主机的定向部署,另外还希望可以将实例从一台宿主机调整部署到另一台宿主机上,从创建到重新规划部署都提供一套规则输出,从而提高用户部署的灵活性并提供自主控制能力。 日前,阿里云宣布正式推出阿里云专有宿主机服务, 专有宿主机(Dedicated Host)是一个基于阿里云虚拟化技术托管的用户独享物理服务器,通过向用户出售整体物理主机的资源,物理独享的单租户环境。可以满足以上安全、合规、自定义部署、自带许可(BYOL)需求。 阿里云作为国内云服务领域的领导者,此次推出的专有宿主机具备国内外云服务厂商所没有的一些独一无二的核心优势,基于阿里云飞天服务和ECS后羿库存调度系统的自主可控统一技术栈,具备几大核心优势: 简单:因为基于统一飞天技术栈,在ECS部署地域都会很快推出专有宿主机服务;用户在购买专有宿主机后直接按需创建ECS实例,和公共云上ECS实例在使用和通用性能指标和功能几乎一致,无门槛上手; 灵活:用户可以在专有宿主机上灵活创建多种规格(同规格族)的ECS实例,接下来也会紧接着推出专有宿主机上ECS实例升降配,用户可以灵活升降配实例规格;同时用户可以将共享宿主机上的ECS实例迁移至专有宿主机,也可以将专有宿主机上的ECS实例迁移至另一台宿主机,做到资源的灵活调度。 极致:针对高端客户,可以定制化主机属性,可以获得有别于共享宿主机上的极致性能指标;比如通过定制化,磁盘可以支持百万级IOPS;网络定制化session可以达到400W,比目前共享云主机session数可以大幅提升300%; 可控:基于阿里云的迁移技术,支持宕机迁移保证业务的连续性;用户也可以选择不宕机迁移,保证业务部署的可控性。 查看 阿里云专有宿主机服务 , ​ 查看详情 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-07-04 15:37:00
摘要: 本文作者:白金,《CDN 之我见》是一个系列文章,共由三个篇章组成,分为“原理篇”、“详解篇”和“陨坑篇”。本篇章属于“详解篇”的第一部分:网络优化。详解篇适合那些接触过 CDN,对 CDN 多少有些了解,但很多知识点知其然而不知其所以然,想深入了解学习的同学。 本文作者:白金 上篇回顾:《CDN 之我见》系列二:原理篇(缓存、安全) https://yq.aliyun.com/articles/599253 《CDN 之我见》是一个系列文章,共由三个篇章组成,分为“原理篇”、“详解篇”和“陨坑篇”。本篇章属于“详解篇”的第一部分:网络优化。详解篇适合那些接触过 CDN,对 CDN 多少有些了解,但很多知识点知其然而不知其所以然,想深入了解学习的同学。 众所周知,当前是互联网时代,无论大大小小的公司,无论是互联网企业还是传统企业,统统离不开一个“网”字,而相比之下,硬件服务器、操作系统、应用组件等,在没有特殊必要需求的话(如果硬件不坏、软件或系统无急需修复的 BUG、无急需实现的客户需求),这些都是不用去主动改变。 相比之下网络则不同,最频繁变化的,最不想变化而又最无奈被动跟随变化的,就是网络质量,而 CDN 的缩写也是 Content Delivery Network,因此在详解篇我会把重点放在网络上。其它的部分相对都好把控,但网络问题存在一定的随机性和不可预测性。如果我们可以驾驭网络,相信在这个互联互通的互联网时代,我们将变得如虎添翼、叱咤风云! 为此,这里提出我对 CDN 的另一个解读:CDN - Can Do sth. on Network(我们可以在网络层面搞些事情) 提到优化,其实从 OSI 七层模型来讲(准确说是 TCP/IP 模型,二者是不同的,具体可以 google 一下),从物理层到应用层其实都是可以优化的,优化手段各异。 L1 物理层:硬件优化(升级硬件设备,承载更多业务) L2 链路层:资源好坏(寻找更快的网络节点、确保 Lastmile 尽量短) L3 路由层:路径优化(寻找 A 到 B 的最短路径) L4 传输层:协议栈优化(TCP Optimization) L7 应用层:能做的事情太多了(主要面向 HTTP 面向业务) 针对 CDN 而言,常用的是 L4 和 L7 的优化,例如上图所述。 分布式就近部署:确保网民访问到的 Cache Server 离他是最近的。 策略性缓存:针对明确已知的图片、CSS、JS 等,若源站更新并不快,但却没有明确高值缓存多长时间,CDN Cache Server 可以自定义一个缓存时间(例如 60s),这样可以确保在 60s 之内的同样请求会快速给出数据而不用穿越整个 Internet 从源站获取。 传输路径优化:寻找从边缘 CDN Cache Server 经 upper CDN Cache Server 到源站的最优传输路径,确保动态传输的数据可以走端到端的最优路径。 连接加速:通过修改协议栈的 Handshake Timer 来实现快速重试,以弥补由于丢包导致的重试超时。 传输层优化:这里主要是指 TCP 协议,针对 TCP 协议可以做很多优化策略,由于篇幅问题后面再讲。 内容预取:解析 WEB 内容,对于里面的 Object,在网民请求之前,优先由 CDN Cache Server 主动获取并缓存下来,以缩短数据交互时间,提升网民体验感。 合并回源:当有多个人先后下载同一个还未缓存住的内容时(例如一个 mp4 视频文件),CDN Cache Server 做到合并连接从 upstream 拿数据,而不是几个请求,几个 to uptream connection,既做到了带宽成本优化,又做到了给 upstream 降载,后请求的人还能享受之前 CDN Cache Server 已经下载过的部分文件,这部分内容直接 HIT,只有当追上第一个 downloader 的时候才一起等待 MISS 数据。 持久连接池:在 Middlemile 之间预先建立好 TCP Connection,并一直保持不断开,当网民有新请求过来时,边缘 CDN Cache Server 直接借助与 upper 建立好连接,直接发送 HTTP 的 GET/POST 报文到 upper CDN Cache Server,进行 TCP “去握手化”,减少由于 TCP 连接建立而造成的时间损耗(多适用于高并发小文件请求)。 主动压缩:很多源站由于规划设计问题或担心负载过高问题,页面中的 HTML、CSS、JS 文件(这种文件具有高度可压缩性)并未压缩传输,此时 CDN Cache Server 可以主动对其进行压缩后传输并缓存,以减少传输量、降低交互时间、提升用户体验感。 Offline:当源站挂了怎么办?网民访问时,会拿不到数据。那么 CDN 此时可以策略性发送最新缓存的一份旧数据给网民,而不是生硬的告知用户不可访问,以提升用户体验感。 总之,优化策略非常多,下面将抽取其中最具通用性的网络部分进行详细阐述。 如前文所述,所谓路径优化就是找到两点间的最优路径。 对于网络而言,A 到 B 最快 ≠ A 距离 B 最近,从广东联通访问福建联通,可能不如广东联通经北京联通再到福建联通更快,因此要对节点做实时探测,计算最优路径。 计算最优路径时,还要考虑带宽饱和度、成本、客户敏感度问题综合计算,因此不是看上去那么简单的。 带宽饱和度:作为中转节点(例如上例所说的北京),如果带宽本身已经没有多少剩余,那么穿越北京的路径优化可能会作为压死大象的最后一根稻草,使原本还 OK 的北京节点变得不堪重负。 成本:还以北京为例,北京资源的带宽成本肯定远高于其它省市,例如比河北联通、天津联通可能要贵很多,但可能只比河北天津慢几个毫秒(运动员起跑时最快的反应时间是 150 毫秒),那么为了这几毫秒要多支付很多带宽费用显然是不值当的,那么利用北京进行中转显然就是不值得的(当然,有的时候就是为了和对手 PK,那也没办法)。 客户敏感度:有了中转路径,提速效果当然是好的,但如前文所述也是有代价的,那么是所有业务流量都走最优路径呢?还是只让个别业务走最优路径呢?这个就要看客户敏感度了。例如重点大客户,例如对质量要求较高的高价优质客户,这些客户可能就是首选。 如前文所述,所谓传输层优化主要是指 TCP 优化,这是所有互联网行业的通用技术,是重中之重的领域,TCP 优化如果做的好,可弥补节点质量低下而造成的响应时间过大的损失。 赛马比赛时,有好马当然跑的快。如果马一般(不是太差),骑手的骑术精湛,或许同样也可以得第一,就是这个道理! 另外一点 TCP 优化重要的原因在于,TCP 是互联网尤其是 CDN 的基础协议,基本上所有业务都是 over TCP 来进行传输的,如果将 TCP 优化做好,受益面非常广,可以说全局收益(不仅是提升客户体验感,也能提升内部支撑系统的使用体验感,例如日志传输、配置下发等)。 谈到 TCP 优化,需要先将 TCP 协议基础知识。需要首先明确一些名词属于的概念。 CWND:Congestion Window,拥塞窗口,负责控制单位时间内,数据发送端的报文发送量。TCP 协议规定,一个 RTT(Round-Trip Time,往返时延,大家常说的 ping 值)时间内,数据发送端只能发送 CWND 个数据包(注意不是字节数)。TCP 协议利用 CWND/RTT 来控制速度。 SS:Slow Start,慢启动阶段。TCP 刚开始传输的时候,速度是慢慢涨起来的,除非遇到丢包,否则速度会一直指数性增长(标准 TCP 协议的拥塞控制算法,例如 cubic 就是如此。很多其它拥塞控制算法或其它厂商可能修改过慢启动增长特性,未必符合指数特性)。 CA:Congestion Avoid,拥塞避免阶段。当 TCP 数据发送方感知到有丢包后,会降低 CWND,此时速度会下降,CWND 再次增长时,不再像 SS 那样指数增,而是线性增(同理,标准 TCP 协议的拥塞控制算法,例如 cubic 是这样,很多其它拥塞控制算法或其它厂商可能修改过慢启动增长特性,未必符合这个特性)。 ssthresh:Slow Start Threshold,慢启动阈值。当数据发送方感知到丢包时,会记录此时的 CWND,并计算合理的 ssthresh 值(ssthresh <= 丢包时的 CWND),当 CWND 重新由小至大增长,直到 sshtresh 时,不再 SS 而是 CA。但因为数据确认超时(数据发送端始终收不到对端的接收确认报文),发送端会骤降 CWND 到最初始的状态。 了解了 TCP 的一些名词属于,其实大致也就了解了 TCP 的运作机制,但是有几点要注意。 1.不同的操作系统、内核版本,initcwnd(初始 CWND)不同 以 Linux 为例,kernel-2.6.18 的 initcwnd 是 2,而 kernel-2.6.32 变成了 10,通过 iproute 软件包中的 ip 命令可以修改 Linux 的 CWND 和 RWND。 具体可以参考一篇 Google 写的 Paper,是他们提出了原始 initcwnd = 2 太小了,需要扩大的理念。 原文请参考: https://developers.google.com/speed/protocols/tcp_initcwnd_techreport.pdf 2.单位时间内(一个 RTT)发送量不是 CWND,而是 min(CWND, RWND) 除了数据发送端有个 CWND 以外,数据接收端还有个 RWND(Receive Window,接收窗口),决定还能接收多少数据,并通过接收确认报文显性告知数据发送端,发送端要参考 CWND 和 RWND 信息决定最终发送的数据量(packet 个数)。管道中究竟能放多少数据,取决于 CWND 和 RWND。 另一个问题:TCP 怎么了?TCP 有什么问题吗? 如果能问出这个问题,证明同学们的关注点是正确的。 TCP 是在上个世纪六七十年代设计的,当时面向的是短距离传输、窄带(可能还是半双工通信)的链路环境。链路本身不太可能丢包,丢包基本都是因为链路拥塞造成的。根据早起的 TCP 拥塞控制算法,丢包 -> 降速,再丢 -> 再降,算法本身的目的是希望通过降速来规避拥塞,进而规避丢包情况。 这个算法本身的理念是正确的,但是随着时代的发展,有了 4G,有了 WiFi,有了长距传输,有了策略性丢包逻辑,导致 TCP 传输过程中,丢包不一定就是拥塞造成的,如果按照传统的“丢包就降速”策略来考虑问题,可能不但不能缓解问题,甚至可能会导致问题更加恶化。 举个例子来说,在一个平均随机丢包 50% 的链路上(平均发出去的包,每 2 个就必然丢 1 个),在这种环境下,发现丢包了,降速发送有用吗?答案毋庸置疑,降速只会让对端收到的有效数据更少。这种环境如何优化呢?很简单,每个包发 2 遍不就可以了?这样对端就会 100% 收到数据了,但代价就是发送端的出口流量是之前的 2 倍。 当然,真正在做 TCP 优化时不是这么简单的,要考虑很多细节,例如如何区分丢包原因,例如该如何控制 CWND,例如如何更早的发现接收端没收到数据,例如当对端无响应时如何快速感知等等等等…… TCP 优化实际上是在用带宽换用户体验感,低成本低质量网络虽然可以通过 TCP 优化提升体验感,但综合成本甚至可能比直接采购优质高价节点更高,效果还未必比优质节点直接服务好。 TCP 之所以叫优化不叫加速,是因为它可以让那些原本应当传输很快,由于算法不合理导致的传输变慢的传输变得快起来,但却不能让那些链路质量原本没有问题的变得更快。 除此之外还有一个优化点,就是 TCP Pacing。 前文我们已经讲过,TCP 是通过 CWND/RTT 来控制传输速率的,在一个 RTT 中,最多只能发 min(CWND, RWND) 这么多数据。但是 TCP 协议栈在发送数据时,是在 RTT 周期之初一股脑将数据发送出去的,这样宏观看没有任何问题,但如果微观看,数据发送波形就像上图那样,一个又一个的凸起。虽然在 RTT 单位时间内发送量恒定,但某微观时间线上的发送速率确实超级猛烈的,这样有可能造成瞬间链路拥塞(尤其是窄带线路)。 原文请参考: https://homes.cs.washington.edu/~tom/pubs/pacing.pdf 通过 TCP 三次握手建连可以测得 RTT,在已知 CWND 的情况下,通过控制发包的时间间隔可以实现 Pacing 效果,使数据包在围观看是均衡发送充满整个 RTT 空间的效果,这样可以避免瞬时拥塞,对窄带链路后需要匀速恒定传输的业务非常有效。 除了 Pacing 以外,还有很多不同的优化算法或策略: 建连优化:TCP 在建立连接时,如果丢包,会进入重试,重试时间是 1s、2s、4s、8s 的指数递增间隔,缩短定时器可以让 TCP 在丢包环境建连时间更快,非常适用于高并发短连接的业务场景。 首包优化:此优化其实没什么实质意义,若要说一定会有意义的话,可能就是满足一些评测标准的需要吧,例如有些客户以首包时间作为性能评判的一个依据。所谓首包时间,简单解释就是从 HTTP Client 发出 GET 请求开始计时,到收到 HTTP 响应的时间。为此,Server 端可以通过 TCP_NODELAY 让服务器先吐出 HTTP 头,再吐出实际内容(分包发送,原本是粘到一起的),来进行提速和优化。据说更有甚者先让服务器无条件返回 "HTTP/" 这几个字符,然后再去 upstream 拿数据。这种做法在真实场景中没有任何帮助,只能欺骗一下探测者罢了,因此还没见过有直接发 "HTTP/" 的,其实是一种作弊行为。 平滑发包:如前文所述,在 RTT 内均匀发包,规避微分时间内的流量突发,尽量避免瞬间拥塞,此处不再赘述。 丢包预判:有些网络的丢包是有规律性的,例如每隔一段时间出现一次丢包,例如每次丢包都连续丢几个等,如果程序能自动发现这个规律(有些不明显),就可以针对性提前多发数据,减少重传时间、提高有效发包率。 RTO 探测:如前文讲 TCP 基础时说过的,若始终收不到 ACK 报文,则需要触发 RTO 定时器。RTO 定时器一般都时间非常长,会浪费很多等待时间,而且一旦 RTO,CWND 就会骤降(标准 TCP),因此利用 Probe 提前与 RTO 去试探,可以规避由于 ACK 报文丢失而导致的速度下降问题。 带宽评估:通过单位时间内收到的 ACK 或 SACK 信息可以得知客户端有效接收速率,通过这个速率可以更合理的控制发包速度。 带宽争抢:有些场景(例如合租)是大家互相挤占带宽的,假如你和室友各 1Mbps 的速度看电影,会把 2Mbps 出口占满,而如果一共有 3 个人看,则没人只能分到 1/3。若此时你的流量流量达到 2Mbps,而他俩还都是 1Mbps,则你至少仍可以分到 2/(2+1+1) * 2Mbps = 1Mbps 的 50% 的带宽,甚至更多,代价就是服务器侧的出口流量加大,增加成本。(TCP 优化的本质就是用带宽换用户体验感) 链路质量记忆:如果一个 Client IP 或一个 C 段 Network,若已经得知了网络质量规律(例如 CWND 多大合适,丢包规律是怎样的等),就可以在下次连接时,优先使用历史经验值,取消慢启动环节直接进入告诉发包状态,以提升客户端接收数据速率。 之前讲的 TCP 优化都是需要去修改代码的,这里有一个不用修改代码的方法,仅修改参数就可以。 内核协议栈参数 net.ipv4.tcp_slow_start_after_idle 默认是开启的,这个参数的用途,是为了规避 CWND 无休止增长,因此在连接不断开,但一段时间不传输数据的话,就将 CWND 收敛到 initcwnd,kernel-2.6.32 是 10,kernel-2.6.18 是 2。因此在 HTTP Connection: keep-alive 的环境下,若连续两个 GET 请求之间存在一定时间间隔,则此时服务器端会降低 CWND 到初始值,当 Client 再次发起 GET 后,服务器会重新进入慢启动流程。 这种友善的保护机制,对于 CDN 来说是帮倒忙,因此我们可以通过命令将此功能关闭,以提高 HTTP Connection: keep-alive 环境下的用户体验感。 # sysctl net.ipv4.tcp_slow_start_after_idle=0 原文链接 本文为云栖社区原创内容,未经允许不得转载。
来源:OSCHINA
发布时间:2018-07-04 15:08:00
应用 是Rainbond可管理的最小服务单元,用户可以将多个应用组成复杂的业务系统,对外提供服务或分享给其他组织独立部署。 Rainbond支持源码、镜像、应用市场等多种方式创建应用,你可以选择适合自己的方式快速起步: 一、通过源代码创建应用 Rainbond源代码创建应用支持Java、PHP、Python、Node.js、Ruby、Golang、HTML等流行编程语言,也支持Dockerfile创建应用,示例如下: 1.1 PHP源码创建应用 源代码地址: https://github.com/goodrain/php-demo.git 点击【创建应用】--【从源码创建】 PHP语言的高级设置 构建应用并访问 1.2 Dockerfile源码创建应用 源代码地址: https://github.com/goodrain/dockerfile-demo.git 点击【创建应用】--【从源码创建】 二、通过Docker镜像创建应用 Rainbond可以通过直接拉取Docker官方或者第三方Docker镜像的方式创建应用,但需要注意的是,第三方Docker仓库一定要支持HTTPS协议,否则需要 修改管理节点docker配置,支持非安全的仓库地址 。除了通过拉取镜像,rainbond还支持 docker run 命令来创建应用,示例如下: 2.1 通过docker镜像创建应用 点击【创建应用】--【从Docker镜像创建应用】--【指定镜像】 2.2 通过docker run命令创建应用 使用如下Docker Run命令创建应用,先复制到剪贴板: docker run -d --name ghost -p 3001:2368 -v /data:/var/lib/ghost/content ghost:1-alpine 点击【创建应用】--【从Docker镜像创建应用】--【Docker Run命令】 2.3 其他语言源码创建应用 Java源码创建应用 PHP源码创建应用 Python源码创建应用 Node.js源码创建应用 Ruby源码创建应用 Golang源码创建应用 HTML静态源码创建应用 Dockerfile源码创建应用 三、通过云市创建应用 除了以上两类应用创建方法,Rainbond还提供了应用市场的一键部署。应用市场是好雨提供的一项公有云服务,提供常用开发应用及工具。以Wordpress为例: 点击【创建应用】--【从云市安装】 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。 Rainbond项目网站 试用Rainbond公有云 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo Github 码云 文档 微信群: 添加微信“zqg5258423”并接受邀请入群
来源:OSCHINA
发布时间:2018-07-04 14:48:00
本次 v3.7.0-rc1 版本,在上月发布3.6.1版本基础上,重点围绕系统生产稳定性展开,包括双重健康检查守护(Systemd进程级加Rainbond-Node业务级)、Prometheus监控指标暴露支持、管理节点上线下线支持等多项新增特性和优化。 除此之外,本次更新还对应用管理功能、安全性和系统安装三方面进行了部分优化,更新详情如下: 稳定性增强 所有平台服务使用Systemd进程级守护加Rainbond-Node业务级健康检查守护 所有平台服务支持健康检查和Prometheus的监控指标暴露 管理节点支持上线和下线以隔离由于节点故障导致的平台不可用 计算节点健康检查异常时支持自动隔离和恢复 支持配置自定义报警规则用于对节点物理监控、服务监控的报警 租户使用资源(内存、磁盘)的统计由单个节点完成(Rainbond-Worker Master节点故障时自动切换) 支持通过命令行工具便捷查询数据中心健康状态、所有节点健康状态 应用管理功能 支持 .NetCore(2.1)语言一键构建应用,运行于Linux系统 支持对接SVN代码仓库持续构建应用 增加自动构建的入口,支持通过自定义API、Gitee-Webhook、Gogs-Webhook触发自动构建,更好的于第三方CI系统集成。 支持应用+插件完整交付应用市场,并从市场安装应用+插件完整业务系统,提供了业务+治理功能扩展绑定的完整软件交付模式 Dockerfile构建支持ARG参数 支持基于Git仓库的代码Tag构建应用 支持应用创建后重新识别语言类型 安全性 数据中心出口API与控制台、命令行工具等客户端使用TSL双向安全认证 用户注册功能管理员可控制,用户加入团队需管理员审核 系统安装 支持Centos7.3及以上,Ubuntu16.04,Debian9及以上完全的离线安装 支持管理节点水平扩容 关于Rainbond Rainbond 是一款以应用为中心的开源PaaS,由好雨基于Docker、Kubernetes等容器技术自主研发,可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台,或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。 Rainbond项目网站 试用Rainbond公有云 注册或使用Demo账号/密码登录:rainbond-demo/rainbond-demo Github 码云 文档 微信群: 添加微信“zqg5258423”并接受邀请入群
来源:OSCHINA
发布时间:2018-08-07 11:55:00
如果你对云计算、大数据、云安全、人工智能领域感兴趣~ 如果你想从事与此相关的工作~~ 如果你又喜欢边交流边学习的方式~ 那么,加入我们吧! 我们将为你提供一个广阔的平台,让你接触到云计算、大数据、云安全、人工智能领域打大牛~~ 为你提供一份当下最热门行业的入门机会~~ 我们希望你: 1. 了解阿里云大学; 2. 有强烈的客户服务意识和责任心,能够及时响应; 3. 具备良好的沟通表达能力和团队合作意识; 4. 性格开朗,做事认真,有强烈的学习意愿,有激情,有活力; *5. 拥有 阿里云云学院 证书 / 阿里云ACA证书 / 阿里云Apsara Cluder认证 (3个及以上); 我们需要你可以胜任以下工作: 1:协助阿里云运营人员进行活动策略的设计与推广; 2:负责阿里云大学互联网学院学生班级的管理、文化建设、内容沉淀等; 3:负责互联网学院辅导老师工作沟通、安排,研究互联网学院内容并给出建设意见; 加入我们你将得到: 1:与阿里云员工共事,学习云计算行业领先运营经验 2:与阿里云专业导师零距离沟通,疑难解答触手可及 3:总结学员在专业学习工作上的问题,积攒“工作经验” 4:参加云计算行业顶级盛宴—云栖大会的机会 5:工作津贴 工作地点: 手机移动工作 机会稍纵即逝,错过遥遥无期,请发送你的【简历】到: tunan.lbb@alibaba-inc.com 邮件命名格式:应聘 +云学院 + 姓名 (如通过简历筛选,小姐姐将在三个工作日内与你联系) 原文链接: http://click.aliyun.com/m/1000010648/
来源:OSCHINA
发布时间:2018-08-06 15:36:00
变量的取值类型 因变量:连续变量,二分类变量,等级变量、多分类变量,连续带有删失变量 解释变量:连续、分类、等级变量 模型选择方式:基本公式(X,Y是否正态分布) 广义线性模型 y不是正态分布 指数分布族 glm()的用法 Logistic模型函数形式: 对数线性模型 分类变量 层次变量 一般线性模型 y正态分布,x非正态分布 完全随机设计方差分析,只考虑一个随机因素 随机单位组设计模型 #建立全变量logistic回归模型 d5.1=read.table('clipboard',header = T) logit<-glm(y~x1+x2+x3,family = binomial,data=d5.1) summary(logit) #逐步筛选变量logistic回归模型 logit.step=step(logit) summary(logit.step) #对数Poisson回归模型 d5.2=read.table('clipboard',header = T) log=glm(y~x1+x2,family=poisson,data=d5.2) summary(log) #一般线性回归模型 d5.3=read.table('clipboard',header = T) #完全随机设计方差分析 anova(lm(Y~factor(A),data = d5.3)) #随机单位组设计模型 d5.4=read.table('clipboard',header = T) anova(lm(Y~factor(A)+factor(B),data = d5.4)) 参考资料: https://next.xuetangx.com/course/JNU07011000851/151569
来源:OSCHINA
发布时间:2020-03-26 22:53:00
漏洞概述 近日,互联网出现watchdogs挖矿病毒,攻击者可以利用Redis未授权访问漏洞入侵服务器,通过内外网扫描感染更多机器。被感染的主机出现 crontab 任务异常、系统文件被删除、CPU 异常等情况,并且会自动感染更多机器,严重影响业务正常运行甚至导致崩溃。 在此,小哥建议您及时开展Redis业务自查并进行升级修复,避免业务和经济损失。 漏洞影响 1、数据泄露。Redis被远程控制,泄漏敏感业务数据 2、病毒感染。如果机器本身未加固,可通过Redis漏洞入侵主机资源,并进行系统破坏、文件删除、利用主机资源挖矿等恶性操作 产生漏洞条件 1、Redis全网监听,暴露于公网之上。自建Redis容易设置0.0.0.0:6379,在绑定EIP之后暴露在互联网上 2、Redis无密码或弱密码进行认证,容易被破解 3、Redis服务以root或高权限账户运行,可通过该用户修改 crontab 任务、执行挖矿操作,系统 netstat 等文件被篡改删除,同时会进一步遍历 known_hosts 中历史登录记录进行感染更多机器 加固建议 1、推荐使用 华为云DCS Redis云服务 ,DCS默认已针对Redis进行加固,且有专业团队维护,不受该漏洞影响,您可以放心使用! 2、禁止外网访问 Redis,需要重启Redis才能生效 3、Redis是否以无密码或弱密码进行验证,请添加强密码验证,需要重启Redis才能生效 4、Redis服务是否以root账户运行,请以低权限运行Redis服务,需要重启Redis才能生效 5、设置安全组或防火墙,对源IP进行访问权限控制 6、禁用config命令避免恶意操作,可使用rename特性把config重命名,增加攻击者使用config指令的难度 7、把Redis默认的6379端口修改为其它端口,增加攻击者获取Redis入口的难度 清理木马 若发现主机被入侵感染,请按照以下方法进行处置 1、隔离感染主机:已中毒计算机尽快隔离,关闭所有网络连接,禁用网卡 2、清理未知计划任务 3、删除恶意动态链接库 /usr/local/lib/libioset.so 4、排查清理 /etc/ld.so.preload 中是否加载3中的恶意动态链接库 5、清理 crontab 异常项,删除恶意任务(无法修改则先执行7-a) 6、终止挖矿进程 7、排查清理可能残留的恶意文件 a) chattr -i /usr/sbin/watchdogs /etc/init.d/watchdogs /var/spool/cron/root /etc/cron.d/root b) chkconfig watchdogs off c) rm -f /usr/sbin/watchdogs /etc/init.d/watchdogs 8、相关系统命令可能被病毒删除,可通过包管理器重新安装或者其他机器拷贝恢复 9、由于文件只读且相关命令被 hook,需要安装 busybox 通过 busybox rm 命令删除 10、重启机器 ​ 注意 修复漏洞前请将资料备份,并进行充分测试。
来源:OSCHINA
发布时间:2019-02-27 11:55:00
时序性数据库Prometheus Author: Lijb Emali: lijb1121@163.com Prometheus 简介 Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统,由工作在 SoundCloud 的 google 前员工在 2012 年创建,作为社区开源项目进行开发,并于 2015 年正式发布。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目。 作为新一代的监控框架,Prometheus 具有以下特点: 强大的多维度数据模型: 时间序列数据通过 metric 名和键值对来区分。 所有的 metrics 都可以设置任意的多维标签。 数据模型更随意,不需要刻意设置为以点分隔的字符串。 可以对数据模型进行聚合,切割和切片操作。 支持双精度浮点类型,标签可以设为全 unicode。 灵活而强大的查询语句(PromQL):在同一个查询语句,可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。 易于管理: Prometheus server 是一个单独的二进制文件,可直接在本地工作,不依赖于分布式存储。 高效:平均每个采样点仅占 3.5 bytes,且一个 Prometheus server 可以处理数百万的 metrics。 使用 pull 模式采集时间序列数据,这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。 可以通过服务发现或者静态配置去获取监控的 targets。 有多种可视化图形界面。 易于伸缩。 需要指出的是,由于数据采集可能会有丢失,所以 Prometheus 不适用对采集数据要 100% 准确的情形。但如果用于记录时间序列数据,Prometheus 具有很大的查询优势,此外,Prometheus 适用于微服务的体系架构。 Prometheus 组成及架构 Prometheus 生态圈中包含了多个组件,其中许多组件是可选的: Prometheus Server : 用于收集和存储时间序列数据。 Client Library : 客户端库,为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时,直接返回实时状态的 metrics。 Push Gateway : 主要用于短期的 jobs。由于这类 jobs 存在时间较短,可能在 Prometheus 来 pull 之前就消失了。为此,这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics,对于机器层面的 metrices,需要使用 node exporter。 Exporters : 用于暴露已有的第三方服务的 metrics 给 Prometheus。 Alertmanager : 从 Prometheus server 端接收到 alerts 后,会进行去除重复数据,分组,并路由到对收的接受方式,发出报警。常见的接收方式有:电子邮件,pagerduty,OpsGenie, webhook 等。 一些其他的工具。 图 1 为 Prometheus 官方文档中的架构图: 图 1. Prometheus 架构图 从上图可以看出,Prometheus 的主要模块包括:Prometheus server, exporters, Pushgateway, PromQL, Alertmanager 以及图形界面。 其大概的工作流程是: Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics,或者接收来自 Pushgateway 发过来的 metrics,或者从其他的 Prometheus server 中拉 metrics。 Prometheus server 在本地存储收集到的 metrics,并运行已定义好的 alert.rules,记录新的时间序列或者向 Alertmanager 推送警报。 Alertmanager 根据配置文件,对接收到的警报进行处理,发出告警。 在图形界面中,可视化采集数据。 Prometheus 相关概念 下面将对 Prometheus 中的数据模型,metric 类型以及 instance 和 job 等概念进行介绍,以便读者在 Prometheus 的配置和使用中可以有一个更好的理解。 数据模型 Prometheus 中存储的数据为时间序列,是由 metric 的名字和一系列的标签(键值对)唯一标识的,不同的标签则代表不同的时间序列。 metric 名字:该名字应该具有语义,一般用于表示 metric 的功能,例如:http_requests_total, 表示 http 请求的总数。其中,metric 名字由 ASCII 字符,数字,下划线,以及冒号组成,且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。 标签:使同一个时间序列有了不同维度的识别。例如 http_requests_total{method="Get"} 表示所有 http 请求中的 Get 请求。当 method="post" 时,则为新的一个 metric。标签中的键由 ASCII 字符,数字,以及下划线组成,且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。 样本:实际的时间序列,每个序列包括一个 float64 的值和一个毫秒级的时间戳。 格式:{
来源:OSCHINA
发布时间:2019-03-08 11:23:00