部署生產級的 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.

通過前面Clouder課程的學習，或許你已經掌握了在云服務器上發布和部署靜態網頁的方法，那么如何搭建一個可以隨時更新內容的動態網站？通過本課程的學習，你將掌握如何在云端搭建全世界使用最多的WordPress網站的方法，并學會網站自定義、管理的操作，來實驗你想要的功能。 課程鏈接： 網站建設：簡單動態網站搭建 學員受益： 零基礎建站：從零開始，一步步教你搭建可以更新內容的動態網站 舉一反三：通過網站主題管理和功能添加，可以將網站擴展為個人博客、小型門戶、企業網站、視頻網站等 認證證書：考試通過即可獲得證書，證明自己擁有云平臺建站的能力 課時介紹： 課程介紹 網站搭建的類型 動態網站的實現方式 搭建網站運行環境 部署與安裝WordPress網站程序 云上WordPress網站的管理 云上WordPress網站的優化 【在線實驗】云上快速搭建WordPress網站 更多精品課程： 阿里云大學官網（阿里云大學 - 官方網站，云生態下的創新人才工場）

簡介 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在同一節點。

如果您的應用程序是面向大量用戶、會吸引大量流量，那么一個不變的目標一定是在高效滿足用戶需求的同時、不讓用戶感知到任何類似于“服務器繁忙！”的情況。這一訴求的典型解決方案是橫向擴展部署，以便有多個應用程序容器可以為用戶請求提供服務。但是，這種技術需要可靠的路由功能，需要可以有效地在多個服務器之間分配流量。本文分享的內容就是要解決負載均衡解決方案的問題。 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生態系統在不斷發展，我相信我們能找到更多適合所有負載均衡細微差別的解決方案！

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 年前，倫敦向世界輸出了地鐵，巴黎輸出了下水道，紐約輸出了電網。今天，中國杭州攜手阿里云，正向世界貢獻數字化城市方案。 杭州，是阿里云技術理想和家國情懷的起點和原點。 作者： 阿里云頭條 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

帶你了解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是不被集群外的客戶端訪問的?？蛻舳苏J證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 本文譯者： 季向遠，北京神舟航天軟件技術有限公司產品經理。 本文版權歸原作者所有。本文版權歸原作者所有。

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

我開發了一個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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

關于阿里云容器服務的詳細內容： 阿里云容器服務使用教程 容器服務（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 能力。 更多精品課程： 阿里云大學官網（ 阿里云大學 - 官方網站，云生態下的創新人才工場 ）

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/

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大?。J單位字節） ，-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指定的目錄，不存在就去創建，存在就不執行后面的命令了，就不創建了。

摘要： 阿里有很多的研發團隊，不同事業部使用的發布流程、分支策略并非整齊劃一，但總體上看是比較規整的。其中有一種主流的發布模式以及對應的分支使用方式，稱為“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/前綴命名。 這條規則很簡單，不過實際的玩法就相當豐富了。 首先，發布分支的用途可以很靈活?；A玩法是將每條發布分支與具體的環境相對應，比如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 也許是一個值得考慮的選擇。 原文鏈接

萬惡的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

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. 項目和命名空間管理 用戶可以創建命名空間并將其分配給項目?！绊椖俊笔且环N新的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集群

大約 8個月前， CNCF 的技術監督委員會 (TOC) 開始著手探究相對較新的 “無服務器計算”世界。 他們想知道： 行業內無服務器領域的發展現狀， 以及是否應該在這個領域做些什么 來幫助社區。 為此，他們決定成立一個新工作組來做這項調查。調查涉及了以下主題： 無服務器計算是什么？ 它與功能即服務以及其他 *aaS 云計算模型有何關系？何時應考慮使用無服務器計算？社區中無服務器計算的現狀 – 例如，您在運行時、框架等方面使用哪些選項？ 無服務器處理模型。這里主要圍繞大多數無服務器平臺中常見的架構進行討論，而不關注任何特定的實施選擇。主要面向那些想要了解它背后工作方式的人。 CNCF 建議。工作組擬定了 TOC 可能要考慮的后續步驟的清單。大多數都涉及到“社區建設”。 工作組認為，要想在這樣一個嶄新的空間迅速獲得互通性案例可能會遭遇重重阻力，但是，通過選擇關注現有供應商中看起來存在某種一致性的領域，我們就可能會循序漸進地朝著正確的方向邁進。 若取得成功，它將使用戶的生活變得更輕松。 因此，無服務器工作組目前正圍繞著定義通用事件格式制定全新的 CloudEvents 規范。 雖然此規范出自“無服務器”工作組之手，但人們已經認識到這種事件格式可以應用于任何事件，而不管處理事件的基礎架構如何。 即刻點擊“ 閱讀原文 ”獲得完整文章，讓我們一起揭開無服務器計算新篇章！

處理數據的機制稱為管道。 在配置級別上，管道描述數據來源和相應的匯合點之間的耦合，用于轉換和公布數據。 此功能由通知代理處理。 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/

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　　　?。H僅下載不安裝 ls /var/cache/yum/x86-64/7/　　　　　　　?。２榭聪螺d的位置 yum list -y 包名 --downloaonly --downloaddir=路徑 # yum reinstall -y 包名 --downloaonly --downloaddir=路徑 ?。Ｖ匦掳惭b到指定下載的目錄 先使用yum　list查看有沒有安裝，然后使用yum?。椋睿螅簦幔欤彀惭b。 指定下載的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

當 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

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 廠商所提供的接入域名即可。 原文鏈接 閱讀更多干貨好文，請關注掃描以下二維碼：

當我試圖部署一個應用到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的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

摘要： 最為常見的【彈窗】反而是最“捉摸不定”的東西。各種類型的彈窗傻傻分不清楚，不知道在什么場景下應該用哪種彈窗。尤其是遇到“二次確認”等場景…… 因此，打算從頭整理移動彈窗的基礎知識，以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：若內容涉及侵權，請聯系管理員，我們將第一時間刪除相關內容。 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

摘要： 東方明珠新媒體如何基于阿里云，搭建了面向第三方的視頻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，投入可能是幾個人。如此才能快速地具備能力，應對當今迅速變化的市場環境。 原文鏈接

摘要： 一個大的商業項目，如何能做到如期完工并準時交付，是有一套標準化的流程和體系來支撐的。 項目管理并不是一個陌生的話題，就像《人月神話》里面提到的阿波羅計劃、曼哈頓工程都是非常經典的案例。對于很多新同學來講，對項目管理沒太大感覺，認為總是在溝通和確認一些細節，對風險的識別有太多體感。其實對于一個大的商業項目，如何能做到如期完工并準時交付，是有一套標準化的流程和體系來支撐的。項目管理是一項綜合素質要求很高的工作，像其中的理論工程體現在： 項目管理的九大知識領域：成本管理、質量管理、時間管理、范圍管理、人力資源管理、溝通管理、風險管理、采購管理和整體管理。每個都是一個專項，需要有理論和長期的經驗積累。 項目管理中的鐵三角：時間、成本和范圍，如何把控好這三方面將決定項目的質量及最終的交付成果。 項目管理的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及開發同學的責任心及相互補位才能做到。 原文鏈接

摘要： 一個大的商業項目，如何能做到如期完工并準時交付，是有一套標準化的流程和體系來支撐的。 項目管理并不是一個陌生的話題，就像《人月神話》里面提到的阿波羅計劃、曼哈頓工程都是非常經典的案例。對于很多新同學來講，對項目管理沒太大感覺，認為總是在溝通和確認一些細節，對風險的識別有太多體感。其實對于一個大的商業項目，如何能做到如期完工并準時交付，是有一套標準化的流程和體系來支撐的。項目管理是一項綜合素質要求很高的工作，像其中的理論工程體現在： 項目管理的九大知識領域：成本管理、質量管理、時間管理、范圍管理、人力資源管理、溝通管理、風險管理、采購管理和整體管理。每個都是一個專項，需要有理論和長期的經驗積累。 項目管理中的鐵三角：時間、成本和范圍，如何把控好這三方面將決定項目的質量及最終的交付成果。 項目管理的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及開發同學的責任心及相互補位才能做到。 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

摘要： 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，到互動白板，短延時直播的方案支持。 原文鏈接

消息觸達能力是物聯網（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規定的數據格式進行通信，其分為控制幀和數據幀?？刂茙前l出心跳幀（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語言模擬過，就不展開了。 從開發的角度，無線接入是物聯網設備端的核心技術，身份設備管理和消息推送技術是物聯網云端的核心技術。而從場景體驗的角度，除了前者，還要包括手機的前端開發技術。

Docker從1.12引入了swarm模式，swarm mode用來管理集群化的docker engines，被稱作swarm?？梢允褂胐ocker 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上

摘要： 融之家技術團隊從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秒延時返回結果，服務異常等等場景。需要能方便模擬，而且不需要研發人員修改任何代碼?；贒ubbo的Filter機制實現了一套Mock平臺，JDQMockFilter會在Consumer端以及Provider端執行。JDQMockFilter拿到請求后會先調用Mock平臺查詢是否有Mock服務。 6、監控 服務拆分后出現大量的服務組件，必須要時刻了微服務運行狀態， Dubbo自帶的簡易監控中心不能滿足我們監控需求。所以基于Dubbo的MonitorService自研了一套監控平臺，實時收集微服務運行期間所產生的成功率、失敗率、平均耗時、最大耗時、并發量、數據傳輸排行等。對于服務的下線，耗時過長都會觸發報警。 7、服務框架預覽 經過4次的架構演變，平臺的穩定性、吞吐量、并發量都有非常大的提升，整個RPC框架也重新定義了，增加了權限平臺，mock平臺，監控平臺。 六、總結 微服務架構可以更好的進行業務解耦，具備更好的擴展性以及獨立性，可以提高研發團隊間的并行化研發速度，提升效率、提高模塊復用性，具備高可用、高并發特性。但微服務架構對服務治理的能力要求比較高，維護成本也會比單體應用高。Dubbo 出生于阿里系，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯網公司；只需要通過 Spring 配置的方式即可完成服務化，對于應用無入侵。我們借助Dubbo完成了微服務重構，目前用戶數以及接口調用量都在不斷提升。 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

很多人都有一個建站的心，但是由于沒有相關的技能，導致最后不了了之。云計算，讓一切變得簡單起來，零基礎也能很快搭建出自己的網站，滿足你的心愿。 建站總體來說分為如下幾步： 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，云棲社區版主，在網站建設開發和云計算領域有多年經驗，致力于以場景化的方式讓云計算，用更加通俗易懂的方式讓更多人體驗云計算，讓云端的計算更質樸的落地。

本文作者為美國著名分析師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的此次大會可能是最具說服力、最具參考價值的，因為客戶的緊張感暴露無遺?？蛻粼谝欢ǔ潭犬a生了認識失調。一方面他們想繼續使用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/

摘要： 當你觀看視頻如遇網絡不好的情況，就會出現卡頓或系統提示切換成標清或流暢的畫質，這個時候你會發現視頻的清析度降低了。高清意味著高分辨以及需要更大的帶寬來支撐，高清和寬帶是一對矛盾體。這屆優酷世界杯直播受到一致好評的關鍵，阿里云“窄帶高清2.0”發揮了重大的作用。 寫在前面 2018年俄羅斯世界杯比賽正在如火如荼進行中，互聯網視頻平臺的入局，新媒體直播賽事的火爆，讓本屆世界杯也有了一個新標簽：掌上世界杯。這意味著，用戶可以更加隨心所欲的“躺著看球”。 半數球迷選擇優酷 超6成認為高清且流暢 根據流媒體網調查數據顯示，今年使用手機看世界杯的用戶中，超過50%的用戶選擇優酷。而在新媒體平臺加入直播的情況下，大部分的用戶對直播的清晰度和流暢度表示滿意。 另外一個數據顯示，光酷喵在世界杯期間就有超過800萬的用戶通過投屏智能電視的方式觀看世界杯，把客廳變成了世界杯的主場。只有真正的高清畫質，才能扛住手機超清屏以及電視超大屏的雙重考驗。 當你觀看視頻如遇網絡不好的情況，就會出現卡頓或系統提示切換成標清或流暢的畫質，這個時候你會發現視頻的清析度降低了。高清意味著高分辨以及需要更大的帶寬來支撐，高清和寬帶是一對矛盾體。這屆優酷世界杯直播受到一致好評的關鍵，阿里云“窄帶高清2.0”發揮了重大的作用。 那窄帶高清究竟是什么呢？ 帶寬成本是視頻服務中非常重的基礎設施成本，如何在保證視頻質量的前提下降低成本是整個鏈路中至關重要的一環。所以，在視頻服務中，視頻的編碼和解碼是非常重要的技術。 業內的轉碼技術從MPEG2，到H.264，到H.265大概是下圖的技術發展曲線，每隔十年的時間，視頻的壓縮率會提升一倍左右，平均下來，每年行業視頻壓縮率能提升只有不到7%。這種客觀發展規律之下，視頻行業內的從業者給對手造成壓倒性的競爭優勢已經變得非常困難。 傳統的視頻編碼以信號的損失量最小作為編碼的目標，力求輸出視頻與輸入視頻的差值最小，但實際上，同樣的編碼損耗，在人眼看起來的清晰度可能相差很大，因為人眼對不同畫面位置的敏感程度是不一樣的。窄帶高清是一套以人眼主觀感受最優為基準的視頻編碼技術，通過對直播內容的智能分析，根據對人眼敏感度進行動態處理與編碼，以達到最佳的主觀清晰度效果。 窄帶高清2.0背后有三套視覺模型 保真度和主觀感受的關系模型 當視頻的保真度越來越高時，人眼逐漸就沒有感受了，所以編碼時卡在失真度并沒有很大變化的臨界點上，就可以適當節省帶寬。下圖為保真度與主觀感受模型關系圖。 分辨率和碼率的關系模型 為了保證在某個網絡條件下能夠流暢播放，視頻的碼率需要有一個上限，在這個上限的條件內，如果分辨率選擇過高，會導致分配給每個像素的比特太少，導致視頻模糊，如果分辨率選擇過低，雖然能夠描述清楚每個像素，但是需要依賴播放器做插值放大，視頻也會模糊。窄帶高清結合了大量視頻樣本的分析，在一定的碼率設定下，會根據視頻的內容智能選擇最合適的分辨率，達到最好的主觀視覺效果。 視覺敏感度模型 窄帶高清會將視頻內容分為人眼容易關注的和人眼容易忽視的部分，并對這些部分做不同的處理。對于人眼容易關注的部分，除了人眼聚焦的區域外，人眼還關注規則的紋理，例如球場中的禁區線，球員的輪廓，這是我們一定要保護的區域，我們會在這些區域做一些調整優化，讓它更加突出，使畫面更有張力。對于人眼容易忽視的部分，例如脫焦區域就，我們可以把這塊的處理省掉，同時，我們也可以去掉一些沒有聚集效應的小細節，以此省掉帶寬。例如，球場中的觀眾席，廣告牌的背景就屬于人眼脫焦的區域或沒有聚集效應的小細節。除此之外，人眼還會非常厭惡毛刺、馬賽克，持續的閃動，我們將這些細節處理得更平緩、清晰，能提升畫面整體觀感。 下圖為窄帶高清對人眼聚焦區域的增強，圖中為梅西準備發定位球的場景，畫面的焦點集中在梅西的臉上，在沒有經過窄帶高清時(左圖)，會發現梅西的臉上很多細節被丟失了，看到的畫面比較平滑，有點像打過一層粉，而經過窄帶高清的編碼(右圖)，臉上的細節被完整的保留下來，并進行了適當的強化，使得畫面有很強的立體感。 窄帶高清世界杯升級版 在引入了以上的三個模型以后，在這次世界杯直播中，窄帶高清還針對足球直播場景，基于機器學習優化了特有的編碼策略，比如足球、草地、球員分別采用特別編碼策略進行優化，大幅提升了比賽畫面的層次感和通透性。 在足球比賽中，畫面經常會在不同場景中切換，如何在場景切換中保持清晰度需要有精巧的碼率控制策略。一方面，視頻碼率不能恒定不變，如果恒定不變，突然的場景切換會導致分配給運動場景的碼率過小，導致畫面模糊。另一方面，視頻碼率不能大幅度波動，如果大幅度波動，會容易導致用戶卡頓，也會導致CDN帶寬發生劇烈波動，這樣的劇烈波動對CDN調度將會是巨大的挑戰。窄帶高清分析視頻畫面的運動劇烈程度，結合對視頻長時間碼率分配的統計學習與實時視頻運動復雜度，在有限的播放器緩沖范圍內進行碼率騰挪，可以在保證指定帶寬下播放流暢的同時盡可能地提高主觀清晰度。 下圖為另一個世界杯轉播公司畫面的（左）與優酷（右）在1080P和480P的畫面對比，當切換到這個細節豐富，且運動劇烈的角球爭搶畫面時，使用窄帶高清和非窄帶高清的效果相差非常巨大。在沒有使用窄帶高清時，會出現對該場景的碼率分配嚴重不足，導致非常糟糕的用戶體驗。 下圖為窄帶高清在不同碼率下的與x264，x265的評測對比，可以看到，無論是主觀評測還是VMAF評分，窄帶高清與普通編碼有一代編碼器的差距，在相同清晰度下可以節約30％帶寬。 寫在最后 阿里云作為強有力的技術作為支撐，和優酷一起解決了體育賽事卡頓、清晰度低的用戶痛點，以高清、流暢、零延時的極致觀看體驗俘獲大批球迷。當然，除了窄帶高清技術之外，阿里視頻云也擁有眾多行業領先技術，目前已經是國內視頻服務體量最大的云計算公司。從阿里云視頻云誕生以來，一直在致力于用自身的技術，去創造一些行業里獨有的東西。阿里云將通過阿里集團多年的技術沉淀，構建不一樣的視頻云服務，讓客戶也變得與眾不同。 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

摘要： 今天我分享的內容分成三個部分： 第一部分是“大前端時代前端監控新的變化”, 講述這些年來，前端監控一些新的視角以及最前沿的一些思考。 第二部分"前端監控的最佳實踐"， 從使用的角度出發，介紹前端監控系統的各種使用姿勢 最后是“阿里云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個數據立方中把指定位置的小格子取出來就行了。計算時間就能大幅壓縮到秒級別。 原文鏈接

摘要： 阿里云專有宿主機為什么能夠成為公共云上的專有資源池 過去幾年，云服務深刻的改變了社會獲取和使用計算能力的方式，云已經逐漸演變成水電一樣的基礎服務，越來越多用戶逐步遷移上公有云，有很多客戶從自有機房遷移上公有云都會遇到如下一些問題： 自帶許可證場景（BYOL）上云 如果用戶已經購買了按物理核數、VM個數或者Socket數授權的許可證，那么用戶希望在公有云上繼續使用這些許可證，并受許可條款的約束，籍此節省許可證費用。包括但不僅限于：Windows Server、SQL Server、Oracle等； 安全合規要求 如果用戶的業務有合規性的要求，如金融類用戶，希望物理服務器獨占，滿足嚴格的物理隔離性要求。與此同時用戶也希望可以將實例部署在指定的物理服務器上，滿足業務運行環境監管要求； 性能穩定性極度敏感場景 如果用戶對服務器計算能力和計算環境的穩定要求都比一般業務高，如游戲類用戶，希望獨占物理機，進一步提升業務CPU、網絡IO資源環境的穩定性，確保游戲穩定可靠地運行； 自主部署的場景 用戶希望可以定義一些規則在公有云上ECS實例的自動化部署，也可以實現指定物理主機的定向部署，另外還希望可以將實例從一臺宿主機調整部署到另一臺宿主機上，從創建到重新規劃部署都提供一套規則輸出，從而提高用戶部署的靈活性并提供自主控制能力。 日前，阿里云宣布正式推出阿里云專有宿主機服務， 專有宿主機（Dedicated Host）是一個基于阿里云虛擬化技術托管的用戶獨享物理服務器，通過向用戶出售整體物理主機的資源，物理獨享的單租戶環境?？梢詽M足以上安全、合規、自定義部署、自帶許可（BYOL）需求。 阿里云作為國內云服務領域的領導者，此次推出的專有宿主機具備國內外云服務廠商所沒有的一些獨一無二的核心優勢，基于阿里云飛天服務和ECS后羿庫存調度系統的自主可控統一技術棧，具備幾大核心優勢： 簡單：因為基于統一飛天技術棧，在ECS部署地域都會很快推出專有宿主機服務；用戶在購買專有宿主機后直接按需創建ECS實例，和公共云上ECS實例在使用和通用性能指標和功能幾乎一致，無門檻上手； 靈活：用戶可以在專有宿主機上靈活創建多種規格(同規格族)的ECS實例，接下來也會緊接著推出專有宿主機上ECS實例升降配,用戶可以靈活升降配實例規格；同時用戶可以將共享宿主機上的ECS實例遷移至專有宿主機，也可以將專有宿主機上的ECS實例遷移至另一臺宿主機，做到資源的靈活調度。 極致：針對高端客戶，可以定制化主機屬性，可以獲得有別于共享宿主機上的極致性能指標；比如通過定制化，磁盤可以支持百萬級IOPS；網絡定制化session可以達到400W，比目前共享云主機session數可以大幅提升300%； 可控：基于阿里云的遷移技術，支持宕機遷移保證業務的連續性；用戶也可以選擇不宕機遷移，保證業務部署的可控性。 查看 阿里云專有宿主機服務 ， ? 查看詳情 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

摘要： 本文作者：白金，《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 原文鏈接 本文為云棲社區原創內容，未經允許不得轉載。

應用 是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”并接受邀請入群

本次 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”并接受邀請入群

如果你對云計算、大數據、云安全、人工智能領域感興趣~ 如果你想從事與此相關的工作~~ 如果你又喜歡邊交流邊學習的方式~ 那么，加入我們吧！ 我們將為你提供一個廣闊的平臺，讓你接觸到云計算、大數據、云安全、人工智能領域打大牛~~ 為你提供一份當下最熱門行業的入門機會~~ 我們希望你： 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/

變量的取值類型 因變量：連續變量，二分類變量，等級變量、多分類變量，連續帶有刪失變量 解釋變量：連續、分類、等級變量 模型選擇方式：基本公式（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

漏洞概述 近日，互聯網出現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、重啟機器 ? 注意 修復漏洞前請將資料備份，并進行充分測試。

時序性數據庫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 的值和一個毫秒級的時間戳。 格式：{=, …}，例如：http_requests_total{method="POST",endpoint="/api/tracks"}。 四種 Metric 類型 Prometheus 客戶端庫主要提供四種主要的 metric 類型： Counter 一種累加的 metric，典型的應用如：請求的個數，結束的任務數， 出現的錯誤數等等。 例如，查詢 http_requests_total{method="get", job="Prometheus", handler="query"} 返回 8，10 秒后，再次查詢，則返回 14。 Gauge 一種常規的 metric，典型的應用如：溫度，運行的 goroutines 的個數。 可以任意加減。 例如：go_goroutines{instance="172.17.0.2", job="Prometheus"} 返回值 147，10 秒后返回 124。 Histogram 可以理解為柱狀圖，典型的應用如：請求持續時間，響應大小。 可以對觀察結果采樣，分組及統計。 例如，查詢 http_request_duration_microseconds_sum{job="Prometheus", handler="query"} 時，返回結果如下： 圖 2. Histogram metric 返回結果圖 Summary 類似于 Histogram, 典型的應用如：請求持續時間，響應大小。 提供觀測值的 count 和 sum 功能。 提供百分位的功能，即可以按百分比劃分跟蹤結果。 instance 和 jobs instance: 一個單獨 scrape 的目標， 一般對應于一個進程。 jobs: 一組同種類型的 instances（主要用于保證可擴展性和可靠性），例如： 1. job 和 instance 的關系 `job: api-server` ` ``instance 1: 1.2.3.4:5670`` ``instance 2: 1.2.3.4:5671`` ``instance 3: 5.6.7.8:5670`` ``instance 4: 5.6.7.8:5671` 當 scrape 目標時，Prometheus 會自動給這個 scrape 的時間序列附加一些標簽以便更好的分別，例如： instance，job。 下面以實際的 metric 為例，對上述概念進行說明。 圖 3. Metrics 示例 如上圖所示，這三個 metric 的名字都一樣，他們僅憑 handler 不同而被標識為不同的 metrics。這類 metrics 只會向上累加，是屬于 Counter 類型的 metric，且 metrics 中都含有 instance 和 job 這兩個標簽。 Node exporter 安裝 為了更好的演示 Prometheus 從配置，到監控，到報警的功能，本實例將引入本機 ubuntu server 的監控。由于 Prometheus 主要用于監控 web 服務，如果需要監控 ubuntu server，則需要在本機上安裝 node exporter。 Node exporter 主要用于暴露 metrics 給 Prometheus，其中 metrics 包括：cpu 的負載，內存的使用情況，網絡等。 安裝 node export 首先需要從 github 中下載最新的 node exporter 包，放在指定的目錄并解壓安裝包，在本實例中，放在 /home/lilly/prom/exporters/ 中。 2. 安裝 Node exporter `cd /home/lilly/prom/exporters/``wget https://github.com/prometheus/node_exporter/releases/download/v0.14.0/node_exporter-0.14.0.linux-amd64.tar.gz``tar -xvzf node_exporter-0.14.0.linux-amd64.tar.gz` 為了更好的啟動和停止 node exporter，可以把 node exporter 轉換為一個服務。 3. 配置 node exporter 為服務 `vim /etc/init/node_exporter.conf``#Prometheus Node Exporter Upstart script`` ``start on startup`` ``script`` ``/home/lilly/prom/exporters/node_exporter/node_exporter`` ``end script` 此時，node exporter 已經是一個服務，可以直接用 service 命令進行啟停和查看。 4. 查看 node exporter 狀態 `root@ubuntu1404-dev:~/alertmanager# service node_exporter start``node_exporter start/running, process 11017``root@ubuntu1404-dev:~/alertmanager# service node_exporter status``node_exporter start/running, process 11017``此時，node exporter 已經監聽在 9100 端口。``root@ubuntu1404-dev:~/prom# netstat -anp | grep 9100``tcp6 0 0 :::9100 :::* LISTEN 155/node_exporter` 當 node exporter 啟動時，可以通過 curl http://localhost:9100/metrics 或者在瀏覽器中查看 ubuntu server 里面的 metrics，部分 metrics 信息如下： 5. 驗證 node exporter `root@ubuntu1404-dev:~/prom# curl http://localhost:9100/metrics``……``# HELP node_cpu Seconds the cpus spent in each mode.``# TYPE node_cpu counter``node_cpu{cpu="cpu0",mode="guest"} 0``node_cpu{cpu="cpu0",mode="idle"} 30.02``node_cpu{cpu="cpu0",mode="iowait"} 0.5``node_cpu{cpu="cpu0",mode="irq"} 0``node_cpu{cpu="cpu0",mode="nice"} 0``node_cpu{cpu="cpu0",mode="softirq"} 0.34``node_cpu{cpu="cpu0",mode="steal"} 0``node_cpu{cpu="cpu0",mode="system"} 5.38``node_cpu{cpu="cpu0",mode="user"} 11.34``# HELP node_disk_bytes_read The total number of bytes read successfully.``# TYPE node_disk_bytes_read counter``node_disk_bytes_read{device="sda"} 5.50009856e+08``node_disk_bytes_read{device="sr0"} 67584``# HELP node_disk_bytes_written The total number of bytes written successfully.``# TYPE node_disk_bytes_written counter``node_disk_bytes_written{device="sda"} 2.0160512e+07``node_disk_bytes_written{device="sr0"} 0``# HELP node_disk_io_now The number of I/Os currently in progress.``# TYPE node_disk_io_now gauge``node_disk_io_now{device="sda"} 0``node_disk_io_now{device="sr0"} 0``# HELP node_disk_io_time_ms Total Milliseconds spent doing I/Os.``# TYPE node_disk_io_time_ms counter``node_disk_io_time_ms{device="sda"} 3484``node_disk_io_time_ms{device="sr0"} 12``……``# HELP node_memory_MemAvailable Memory information field MemAvailable.``# TYPE node_memory_MemAvailable gauge``node_memory_MemAvailable 1.373270016e+09``# HELP node_memory_MemFree Memory information field MemFree.``# TYPE node_memory_MemFree gauge``node_memory_MemFree 9.2403712e+08``# HELP node_memory_MemTotal Memory information field MemTotal.``# TYPE node_memory_MemTotal gauge``node_memory_MemTotal 2.098388992e+09``……``# HELP node_network_receive_drop Network device statistic receive_drop.``# TYPE node_network_receive_drop gauge``node_network_receive_drop{device="docker0"} 0``node_network_receive_drop{device="eth0"} 0``node_network_receive_drop{device="eth1"} 0``node_network_receive_drop{device="lo"} 0` Prometheus 安裝和配置 Prometheus 可以采用多種方式安裝，本文直接用官網的 docker image（prom/prometheus）啟動一個 Prometheus server, 并配置相應的靜態監控 targets，jobs 和 alert.rules 文件。 啟動 Prometheus 容器，并把服務綁定在本機的 9090 端口。命令如下： 6. 安裝 Prometheus `docker run -d -p 9090:9090 \`` ``-v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml \`` ``-v $PWD/alert.rules:/etc/prometheus/alert.rules \`` ``--name prometheus \`` ``prom/prometheus \`` ``-config.file=/etc/prometheus/prometheus.yml \`` ``-alertmanager.url=http://10.0.2.15:9093` 其中 Prometheus 的配置文件 prometheus.yml 內容為： 7. Prometheus.yml 配置文件 global: ? ? ? ? ? ? ? ? ?# 全局設置，可以被覆蓋 scrape_interval: ? ? 15s # 默認值為 15s，用于設置每次數據收集的間隔 external_labels: ? # 所有時間序列和警告與外部通信時用的外部標簽 ? monitor: 'codelab-monitor' rule_files: # 警告規則設置文件 - '/etc/prometheus/alert.rules' # 用于配置 scrape 的 endpoint 配置需要 scrape 的 targets 以及相應的參數 scrape_configs: ?# The job name is added as a label `job=` to any timeseries scraped from this config. - job_name: 'prometheus' ?# 一定要全局唯一, 采集 Prometheus 自身的 metrics ? ?# 覆蓋全局的 scrape_interval ? scrape_interval: 5s ? static_configs: ?# 靜態目標的配置 ? ? - targets: ['172.17.0.2:9090'] - job_name: 'node' ?# 一定要全局唯一, 采集本機的 metrics，需要在本機安裝 node_exporter ? scrape_interval: 10s ? static_configs: ? ? - targets: ['10.0.2.15:9100'] ?# 本機 node_exporter 的 endpoint alert 規則文件的內容如下： 8. alert.rules 配置文件 # Alert for any instance that is unreachable for >5 minutes. ALERT InstanceDown ? # alert 名字 IF up == 0 ? ? ? ? ? # 判斷條件 FOR 5m ? ? ? ? ? ? # 條件保持 5m 才會發出 alert LABELS { severity = "critical" } ?# 設置 alert 的標簽 ANNOTATIONS { ? ? ? ? ? ? # alert 的其他標簽，但不用于標識 alert ? summary = "Instance {{ $labels.instance }} down", ? description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.", ?} 當 Prometheus server 起來時，可以在 Prometheus 容器的日志中看到： 9. Prometheus 日志 time="2017-09-05T08:18:02Z" level=info msg="Starting prometheus (version=1.7.1, branch=master, revision=3afb3fffa3a29c3de865e1172fb740442e9d0133)" source="main.go:88" time="2017-09-05T08:18:02Z" level=info msg="Build context (go=go1.8.3, user=root@0aa1b7fc430d, date=20170612- 11:44:05)" source="main.go:89" time="2017-09-05T08:18:02Z" level=info msg="Host details (Linux 3.19.0-75-generic #83~14.04.1-Ubuntu SMP Thu Nov 10 10:51:40 UTC 2016 x86_64 71984d75e6a1 (none))" source="main.go:90" time="2017-09-05T08:18:02Z" level=info msg="Loading configuration file /etc/prometheus/prometheus.yml" source="main.go:252" time="2017-09-05T08:18:03Z" level=info msg="Loading series map and head chunks..." source="storage.go:428" time="2017-09-05T08:18:03Z" level=info msg="0 series loaded." source="storage.go:439" time="2017-09-05T08:18:03Z" level=info msg="Starting target manager..." source="targetmanager.go:63" time="2017-09-05T08:18:03Z" level=info msg="Listening on :9090" source="web.go:259" 在瀏覽器中訪問 Prometheus 的主頁 http://localhost:9091 , 可以看到 Prometheus 的信息如下： 圖 4. Prometheus 狀態信息 為了保證 Prometheus 確實從 node exporter 中收集數據，可以在 Graph 頁面中搜索 metric 名字，如 node_cpu 并點擊 Execute，可以在 console 中看到 metric 如下。 圖 5. Prometheus 中 metric 查詢結果 console 輸出示例 其中第一條為來自 node exporter 的 metric，此時 ubuntu server 上 goroutines 的個數為 13。點擊 Graph 可以觀察 metrics 的歷史數據。如下圖所示： 圖 6. Prometheus 中 metric 查詢結果 Graph 輸出示例 Alertmanager 安裝和配置 當接收到 Prometheus 端發送過來的 alerts 時，Alertmanager 會對 alerts 進行去重復，分組，路由到對應集成的接受端，包括：slack，電子郵件，pagerduty，hitchat，webhook。 在 Alertmanager 的配置文件中，需要進行如下配置： 10. Alermanager 中 config.yml 文件 root@ubuntu1404-dev:~/alertmanager# cat config.yml global: resolve_timeout: 5m route: receiver: 'default-receiver' group_wait: 30s group_interval: 1m repeat_interval: 1m group_by: ['alertname'] routes: - match: severity: critical receiver: my-slack receivers: - name: 'my-slack' slack_configs: - send_resolved: true api_url: https://hooks.slack.com/services/*** channel: '#alertmanager-critical' text: "{{ .CommonAnnotations.description }}" - name: 'default-receiver' slack_configs: - send_resolved: true api_url: https://hooks.slack.com/services/*** channel: '#alertmanager-default' text: "{{ .CommonAnnotations.description }}" 創建好 config.yml 文件后，可以直接用 docker 啟動一個 Alertmanager 的容器，如下： 11. 安裝 Alertmanager 當 Alertmanager 服務起來時，可以通過瀏覽器訪 Alertmanager 的主頁 http://localhost:9093 ，其狀態信息如下： 圖 7. Alertmanager 狀態信息 在 alerts 的頁面中，我們可以看到從 Prometheus sever 端發過來的 alerts，此外，還可以做 alerts 搜索，分組，靜音等操作。 圖 8. Alertmanager 報警頁面 Prometheus 實例演示 下面將通過一個具體的實例來演示 Prometheus 的使用。在 alert.ruels 中定義了 alert 觸發的條件是 up 為 0。下面，手動停止 node exporter 服務。 清單 12. 停止 node exporter 服務 `root@ubuntu1404-dev:~/prom# service node_exporter stop``node_exporter stop/waiting``root@ubuntu1404-dev:~/prom# service node_exporter status``node_exporter stop/waiting` 此時，Prometheus 中查詢 metric up,可以看到此時 up{instance="10.0.2.15",job="node"} 的值為 0，如下所示： 圖 9. Metric up 的返回值（停） 此時，Alerts 頁面中顯示 InstanceDown，狀態為 PENDING。因為 alert 規則中定義需要保持 5 分鐘，所以在這之前，alerts 還沒有發送至 Alertmanager。 圖 10. Alert Pending 界面 5 分鐘后，狀態由 PENDING 變為 FIRING，于此同時，在 Alertmanager 中可以看到有一個 alert。 圖 11. Alert Firing 界面 圖 12. Alertmanager 警報界面 在 Alertmanager 的配置文件中定義，黨 severity 為 critical 的時候，往 Alertmanager-critical channel 中發送警告，且每隔兩分鐘重復發送。如下圖所示。 圖 13. Slack 告警界面 由上可知，當目標失敗時，不僅可以在 Prometheus 的主頁上實時的查看目標和 alerts 的狀態，還可以使用 Alertmanager 發送警告，以便運維人員盡快解決問題。 當問題解決后，Prometheus 不僅會實時更新 metrics 的狀態，Alertmanager 也會在 slack 通知 resolved 的消息。以下演示問題解決后的，Prometheus 的操作。 手動啟動 node exporter。首先 metric 在 Graph 中恢復至正常值 1。 圖 14. Metric up 的返回值（啟） targets 中現實 node 這個 job 是 up 的狀態。 圖 15. Targets 界面 Alerts 為綠色，顯示有 0 個激活態的警告。 圖 16. Alers resolved 界面 而在 Alertmanager 剛剛的 alert 也被清空，顯示 No alerts found。 圖 17. Alertmanager resolved 界面 在 slack 端，在多次紅色 FRING 報警后，也收到了綠色了 RESOLVED 消息。 圖 18. Slack resolved 界面 總結 本文對 Prometheus 的組成，架構和基本概念進行了介紹，并實例演示了 node exporter, Prometheus 和 Alermanager 的配置和運行。最后，以一個監控的 target 的啟停為例，演示 Prometheus 的一系列響應以及如何在 Prometheus 和 Alertmanager 中查看服務，警報和告警的狀態。對于 Prometheus 中更高級的使用，如查詢函數的使用，更多圖形界面的集成，請參考官方文檔。 參考資源 Prometheus 概念及詳細配置請參閱 Prometheus 官方文檔 Node exporter 安裝請參考 node_exporter github 倉庫 Slack 信息發送請參考 Incoming Webhooks