如何设计高可用配置中心

A. 架构高可用高并发系统的设计原则

通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨菲定律、康威定律和二八定律三大定律，而系统设计包括高并发原则、高可用和业务设计原则等。
架构设计三大定律
墨菲定律 – 任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生
康威定律 – 系统架构师公司组织架构的反映 – 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 – 如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 – 微服务架构的理论基础 – 康威定律https://yq.aliyun.com/articles/8611– 每个架构师都应该研究下康威定律http://36kr.com/p/5042735.html
二八定律 – 80%的结果取决于20%的原因
系统设计遵循的原则
1.高并发原则
无状态
无状态应用，便于水平扩展
有状态配置可通过配置中心实现无状态
实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系统维度：按照系统功能、业务拆分，如购物车，结算，订单等
功能维度：对系统功能在做细粒度拆分
读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统
模块维度：对整体代码结构划分Web、Service、DAO
服务化
服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服
消息队列
目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等
大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)
数据校对: 解决异步消息机制下消息丢失问题
数据异构
数据异构: 通过消息队列机制接收数据变更，原子化存储
数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环
缓存银弹
用户层:
DNS缓存
浏览器DNS缓存
操作系统DNS缓存
本地DNS服务商缓存
DNS服务器缓存
客户端缓存
浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)
App客户缓存(js/css/image…)
代理层：
CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)
接入层：
Opcache： 缓存PHP的Opcodes
Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 业务数据缓存
Nginx为例：
PHP为例：
应用层：
页面静态化
业务数据缓存(Redis/Memcached/本地文件等)
消息队列
数据层：
NoSQL： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系统层：
CPU : L1/L2/L3 Cache/NUMA
内存
磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存
并发化
2.高可用原则
降级
降级开关集中化管理：将开关配置信息推送到各个应用
可降级的多级读服务：如服务调用降级为只读本地缓存
开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略
业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能
限流
目的: 防止恶意请求攻击或超出系统峰值
实践：
恶意请求流量只访问到Cache
穿透后端应用的流量使用Nginx的limit处理
恶意IP使用Nginx Deny策略或者iptables拒绝
切流量
目的：屏蔽故障机器
实践:
DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢
HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
LVS/HaProxy/Nginx: 摘除故障节点
可回滚
发布版本失败时可随时快速回退到上一个稳定版本
3.业务设计原则
防重设计
幂等设计
流程定义
状态与状态机
后台系统操作可反馈
后台系统审批化
文档注释
备份
4.总结
先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。
本文作者为网易高级运维工程师

B. 如何在Kubernetes中部署一个高可用的PostgreSQL集群环境

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中，支持配置各种不同的存储。
如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。

C. 静脉药物配置中心如何设计建设

喜格实验室工程：静脉药物配置中心设计建设，如下
1静脉药物配置中心的建立
1.1某院PIVAS位于医院医技楼六楼，便于药品运输和成品配送，便于配制管理和环境控制，水电等基础条件符合规定。其面积309m2，设计合理，流程顺畅。主要功能区域包括排药、贮药、充配、信息、核发、更衣、洗洁等;配有6台生物安全柜和先进的空气净化系统。无菌工作间有严密的隔离措施及消毒设备，进入工作间，必须经过两道隔离门，并安装了空调设备。工程完工后由具有检测资质的单位对净化系统进行静态检测，沉降菌、微粒、噪音、照度、换气次数、温湿度等各项指标达标后，方才投入使用。保证了洁净室的洁净度，从而确保临床用药安全。
1.2某院PIVAS的管理模式采用以药为主，由药剂科负责日常工作管理，护理部负责护理人员的配备，现有药师5名，护师13名，工友2名，为医院19个病区进行服务，每天提供约1 500袋静脉液体。药学人员主要负责审方、排药、加药、核对、药品管理等;护理人员职责为复核、冲配、帮助排药;工勤人员需及时运送药品与打扫卫生等。
1.3信息系统是实现静脉药物配制的基础，分管院长多次召集药剂科、护理部、医务处、信息科的相关人员协调工作、统一认识确定电脑程序。电脑信息系统包括处方传输、标签打印、药费支付、药品管理、咨询服务、药历生成;标签内容应包括患者基本信息、药品处方信息、配制核对信息等，是药师审核用药与记录配制过程的重要凭证。信息管理系统应设置管理权限，完善数据统计的功能，自动生成批次，实行配置全程化管理。另外还将在系统中嵌入配伍监控系统，对用药实施合理用药监控。
2静脉药物配置中心工作流程设计
2.1医生按照《处方管理办法》有关规定开具静脉用药处方，由专人将处方输入医院的信息系统中。处方可分为两类：长期处方与临时处方。病区负责按规定时间将患者次日需要静脉输液的长期处方传送至PIVAS，临时处方按照医院的相关规定和要求传入PIVAS。
2.2 PIVAS的药师接收到处方后，逐一核对患者处方信息，审核确认其正确性、合理性与完整性。对于处方存在错误的，及时与医生沟通，请其调整并签名。对于处方存在错误而医生拒绝不同意修改的，拒绝调配，并报请相关部门协调解决。
2.3经药师审核通过的处方打印成处方标签，标签上需有患者姓名、病区、床号、日期、处方组成、自动生成的编号等内容，且要有各个工序签名或盖章的空间，标签需能贴到输液瓶(袋)上。
2.4药师接到审方合格的标签，应仔细核查标签内容是否准确、完整，如有错误或不全应告知审方药师校对纠正。药师根据审核后的标签上所列药物的顺序，按照其性质、不同的用药时间，分批次将药品放置于不同颜色的容器中，并在标签上签名或盖章，按照病区、药物的不同性质放置于不同的配置间内。
2.5配置间为洁净间，洁净级别为万级，按照配置药物的种类不同可分为普通药物与全静脉营养药配置间、抗生素与细胞毒性药物配置间。普通药物与全静脉营养药配置间需配备净化层流台，使配置环境达到百级，从而保证药品不被污染。抗生素与细胞毒性药物配置间主要配置含有抗生素或细胞毒性药物的处方，本房间配备生物安全柜，使配置环境的洁净级别达到百级，且为负压，从而防止药品对工作人员的伤害。护士严格遵守无菌操作原则及时充配好药品并在其标签上签名或盖章。
2.6完成冲配的药物经传递窗或传送带等方式传送到成品核对包装区，进行再次核对与确认，并按照病区分类装入密闭的容器中，并附成品随行单，由专人送至各个病区。病区护士接收并核对，无误后，给患者用药。盛放药物的容器需能密封，且定期消毒，避免冲配好的药物受到二次污染。

D. maxwell如何实现高可用

一旦我们在信息中心的服务器中实施了虚拟化技术，任何一台物理服务器的断电都会导致多个虚拟机停止工作。一个高可用的(HA)集群系统可以帮助我们预防这种情况出现，当主机故障发生后，虚拟机可以在集群系统中迅速重建。举例来说，假设虚拟化集群中的一个物理节点失效，虚拟机可以迅速迁移到其他节点继续运行。在这种集群模式下，即使在服务器宕机的情况下，核心业务系统仍然可以持续地提供服务。
在Xen虚拟机可以被集群系统管理并实现在节点间自由迁移之前，所有节点必须具备访问虚拟机的配置文件及后端存储的能力。在本文中，TechTarget中国的特约虚拟化专家Sander van Vugt将讲述如何对它们实现共享访问。
实现对虚拟机配置文件的访问
实现虚拟机配置文件在所有节点的共享访问是非常简单的。首先，把文件存放在SAN系统中的逻辑单元号LUN（logic unitnumber）上；接下来，把LUN中/etc/xen/vm目录映射给节点中所有相关主机；最后，把配置文件设置为网络共享状态，使其所在目录可以被主机动态加载。或者您也可以在配置发生变化后，手动同步文件（而且这种变化并不会经常发生）。然而，为了虚拟机后端存储的共享访问，设置方式是完全不同的。

E. Lync服务器如何做高可用，我们公司大约有8000多用户，请给点建议。

如果是Lync Server 2013 的话，建议新建一个前端池，在池里部署3台前端服务器，使用dns负载均衡和硬件负载均衡混搭的方式实现高可用。

在后端部署3太SQL
服务器，其中两台做镜像，第三台做见证服务器。

部署2台office
web app servers 来提供PPT共享的功能。
如果要外部访问Lync，
你需要在DMZ区域部署2台边缘服务器实现高可用

F. 如何为高可用集群Hyper-V系统选择合适的硬件配置

和其他的虚拟机技术环境中不同的是，Hyper-V不能支持内存过分配技术（memory
overcommit
）。因此，当创建的虚拟机所占用的内存总数大于主机实际的物理内存时，您将无法启动虚拟机。如果您在分配完可用物理内存之后，尝试去启动另外的虚拟机，即
使只是再多分配一台，结果只有一种可能就是返回错误提示信息。
如果在一台服务器环境中，这不会是一个大问题，因为所有的虚拟机启动过程都是由管理员人工管理的。在带有自动故障切换技术的集群环境中，这点就会变成一个
很大的障碍。因此，搭建一个拥有足够的可用物理内存的Hyper-V集群环境就变得非常重要，只有满足这个条件后主机才可以成功的从发生故障的源节点切换
到集群中的可用目标节点。这也就是说，如果在一个拥有两个节点的集群中，一半的物理内存必须预留出来；假如拥有四个节点，就意味着需要预留四分之一的物理
内存，以此类推。
简单错误三：缺少支持CSV（Cluster
Shared
Volume，即集群共享卷）技术的备份方式
在Windows
Server
2008
R2中，微软发布了一项称为Cluster
Shared
Volume的新技术。它基于现有NTFS格式文件系统基础上，为Hyper-V虚拟机提供特殊功能支持的技术。您可以把这项技术认为是R2版本的一个属
性，使得分布在集群中的多个虚拟机可以同时访问一个共享的LUN。这项新技术解决了集群中的节点失效时，磁盘子系统也作为其一部分而无法工作的情况。允许
必要情况下，虚拟机可以在一个LUN内无缝地迁移。
CSV技术面临一项潜在的挑战，那就是：很少有基于虚拟主机的备份产品可以支持。今天，甚至于
微软的Windows
Server
Backup也无法实现支持。即使这样，还是有一些像Data
Protection
Manager
2010（仍然只有测试版本）这样的产品，可以实现对这种工作方式的支持。
简单错误四：对虚拟CPU的过度分配
今天，用户购买带有两个及更多物理CPU的服务器已经很普遍。拥有更多的CPU意味着多线程应用程序可以在多个CPU之间实现负载均衡。或者当其中一个
CPU被某个单线程应用所占用时，还可以使用剩余的CPU来满足其他应用的需求。这就是为什么现在几乎所有的服务器都有至少两个甚至有时是四个或更多
CPU的原因。现在的数据中心工作负载需要配备额外的处理器资源以满足性能以及可用性方面的需求。
在Hyper-V的虚拟化环境中，对虚拟处理器的分配方式是比较特别的。Hyper-V的虚拟机环境中的最佳做法是：在初期只为一台物理机分配一个单独的虚拟处理器，只有在需要的情况下才去分配额外的处理器资源。
虽然表面看起来增加虚拟处理器数量是一个很好的方式，但实际上这种操作反而会由于调度管理上引起的冲突而降低性能。当多个虚拟处理器被分配给虚拟机后，
这些处理器必须通过调度管理的方式，把它们的使用情况跟实际的物理资源对应起来。假设两个虚拟处理器分配给一台虚拟机，hypervisor的调度程序
（scheler）必须等待对应的两个物理处理器都可用后再去分配虚拟处理器。当在多个虚拟机竞争处理资源时，每个请求的响应时间会变得比普通情况长
得多。当物理处理器的个数少于所有虚拟机中分配的虚拟处理器之和时，情况甚至还会变得更糟。（关于这种情况为什么会产生，您可以参考文章
Microsoft
Developers
Network
site中的Measuring
Processor
Performanc部分。）
还有，请时刻谨记，管理程序（hypervisor）分配的虚拟处理器需要横跨服务器上所有可用的物理处理器。这样，虚拟处理器才可以充分利用所有可用的物理处理器资源。

G. 如何搭建模块化数据中心

模块化机房其实就是把机房的所有功能集成到一个模块化一体化产品中，这个一体化产品可以看成一个机房，把这个产品布置在一个房间内就可以使用了，而房间不用做太多的装修。

模块化机房（一体化模块化产品）含有机柜、配电柜、UPS、精密空调、动环监控系统、冷通道、电池柜等，由这些产品组成一个封闭空间。每个产品可以看成一个模块，就像搭积木一样组合起来就成了一个模块化机房，你可以根据自己的需求增添产品。

传统机房的规划设计、运营管理都较为落后，而模块化机房却因其高性价比、高可用性的建设模式，获得众人熟知并认可，可见“模块化”理念愈加深入人心。那么，模块化机房优点体现在哪？和传统机房在建设模式上又有那几点区别呢？

区别之一：模式

传统机房：常见的UPS&电池房+空调房+IT机房模式。

模块化机房：批量复制、按需扩展，实行三房归一，快速部署能力适应发展需求。

模块化机房

区别之五：管理

传统机房：专人值守，无完善监控及告警管理。

模块化机房：本地采集、云端汇总，实时监控，交互式告警。单模块监控与集群监控提高运维效率，实现智能管理。

正因以上五点区别，可看出模块化机房优点：在建设上相较于传统建设模式更具优势性。模块化机房不仅满足了业务需求，还能减轻企业成本、提高管理效率。

H. 开发自动化运维架构六要素

运维自动化是我们所渴望获得的，但是我们在一味强调自动化能力时，却忽略了影响自动化落地的一个关键因素。那便是跟运维朝夕相处，让人又爱又恨的业务架构。
要点一：架构独立
任何架构的产生都是为了满足特定的业务诉求，如果我们在满足业务要求的同时，能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。
站在运维的角度，所诉求的架构独立包含四个方面：独立部署，独立测试，组件化和技术解耦。
独立部署
指的是一份源代码，可以按照便于运维的管理要求去部署、升级、伸缩等，可通过配置来区分地域分布。服务间相互调用通过接口请求实现，部署独立性也是运维独立性的前提。
独立测试
运维能够通过一些便捷的测试用例或者工具，验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力，而不需要每次发布或变更都需要开发或测试人员的参与。
组件规范
指的是在同一个公司内对相关的技术能有很好的框架支持，从而避免不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。
这种做法能够限制运维对象的无序增加，让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入，来围绕着标准组件做更多的效率与质量的建设工作。
技术解耦
指的是降低服务和服务之间相互依赖的关系，也包含了降低代码对配置文件的依赖。这也是实现微服务的基础，实现独立部署、独立测试、组件化的基础。
要点二：部署友好
DevOps 中有大量的篇幅讲述持续交付的技术实践，希望从端到端打通开发、测试、运维的所有技术环节，以实现快速部署和交付价值的目标。可见，部署是运维日常工作很重要的组成部分，是属于计划内的工作，重复度高，必须提升效率。
实现高效可靠的部署能力，要做好全局规划，以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的：
CMDB配置
在每次部署操作前，运维需要清晰的掌握该应用与架构、与业务的关系，为了更好的全局理解和评估工作量和潜在风险。
在织云自动化运维平台中，我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显，集中存储运维对象的配置信息，对日后涉及的运维操作、监控和告警等自动化能力建设，将提供大量的配置数据支撑和决策辅助的功效。
环境配置
在运维标准化程度不高的企业中，阻碍部署交付效率的原罪之一便是环境配置，这也是容器化技术主要希望解决的运维痛点之一。
腾讯的运维实践中，对开发、测试、生产三大主要环境的标准化管理，通过枚举纳管与环境相关的资源集合与运维操作，结合自动初始化工具以实现标准环境管理的落地。
依赖管理
解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中，我们利用包管理，将依赖的库文件或环境的配置，通过整体打包和前后置执行脚本的方案，解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法，也是不错的选择。
部署方式
持续交付原则提到要打造可靠可重复的交付流水线，对应用软件的部署操作，我们也强烈按此目标来规划。业界有很多案例可以参考，如Docker的Build、Ship、Run，如织云的通过配置描述、标准化流程的一键部署等等。
发布自测
发布自测包含两部分：
应用的轻量级测试；
发布/变更内容的校对。
建设这两种能力以应对不同的运维场景需求，如在增量发布时，使用发布内容的校对能力，运维人员可快速的获取变更文件md5，或对相关的进程和端口的配置信息进行检查比对，确保每次发布变更的可靠。
同理，轻量级测试则是满足发布时对服务可用性检测的需求，此步骤可以检测服务的连通性，也可以跑些主干的测试用例。
灰度上线
在《日常运维三十六计》中有这么一句话：对不可逆的删除或修改操作，尽量延迟或慢速执行。这便是灰度的思想，无论是从用户、时间、服务器等纬度的灰度上线，都是希望尽量降低上线操作的风险，业务架构支持灰度发布的能力，让应用部署过程的风险降低，对运维更友好。
要点三：可运维性
运维脑海中最理想的微服务架构，首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构，对运维团队带来的不仅仅是黑锅，还有对他们职业发展的深深的伤害，因为维护一个没有可运维性的架构，简直就是在浪费运维人员的生命。
可运维性按操作规范和管理规范可以被归纳为以下七点：
配置管理
在微服务架构管理中，我们提议将应用的二进制文件与配置分离管理，以便于实现独立部署的目的。
被分离出来的应用配置，有三种管理办法：
文件模式；
配置项模式；
分布式配置中心模式。
限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法，关键是要求各业务使用一致的方案，运维便可以有针对性的建设工具和系统来做好配置管理。
版本管理
DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言，想要管理好它，就必须能够清晰的描述它。
和源代码管理的要求类似，运维也需要对日常操作的对象，如包、配置、脚本等都进行脚本化管理，以备在运维系统在完成自动化操作时，能够准确无误的选定被操作的对象和版本。
标准操作
运维日常有大量重复度高的工作需要被执行，从精益思想的视角看，这里存在极大的浪费：学习成本、无价值操作、重复建设的脚本/工具、人肉执行的风险等等。
倘若能在企业内形成统一的运维操作规范，如文件传输、远程执行、应用启动停止等等操作都被规范化、集中化、一键化的操作，运维的效率和质量将得以极大的提升。
进程管理
包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等，被收纳在进程管理的范畴。做好进程管理的全局规划，能够极大的提升自动化运维程度，减少计划外任务的发生。
空间管理
做好磁盘空间使用的管理，是为了保证业务数据的有序存放，也是降低计划外任务发生的有效手段。
要求提前做好的规划：备份策略、存储方案、容量预警、清理策略等，辅以行之有效的工具，让这些任务不再困扰运维。
日志管理
日志规范的推行和贯彻需要研发密切配合，在实践中得出的经验，运维理想中的日志规范要包含这些要求：
业务数据与日志分离
日志与业务逻辑解耦
日志格式统一
返回码及注释清晰
可获取业务指标（请求量/成功率/延时）
定义关键事件
输出级别
管理方案（存放时长、压缩备份等）
当具体上述条件的日志规范得以落地，开发、运维和业务都能相应的获得较好的监控分析能力。
集中管控
运维的工作先天就容易被切割成不同的部分，发布变更、监控分析、故障处理、项目支持、多云管理等等，我们诉求一站式的运维管理平台，使得所有的工作信息能够衔接起来和传承经验，杜绝因为信息孤岛或人工传递信息而造成的运营风险，提升整体运维管控的效率和质量。
要点四：容错容灾
在腾讯技术运营（运维）的四大职责：质量、效率、成本、安全。质量是首要保障的阵地，转换成架构的视角，运维眼中理想的高可用架构架构设计应该包含以下几点：
负载均衡
无论是软件或硬件的负责均衡的方案，从运维的角度出发，我们总希望业务架构是无状态的，路由寻址是智能化的，集群容错是自动实现的。
在腾讯多年的路由软件实践中，软件的负载均衡方案被广泛应用，为业务架构实现高可用立下汗马功劳。
可调度性
在移动互联网盛行的年代，可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时，将用户或服务调离异常区域，是海量运营实践中屡试不爽的技巧，也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。
结合域名、VIP、接入网关等技术，让架构支持调度的能力，丰富运维管理手段，有能力更从容的应对各种故障场景。
异地多活
异地多活是数据高可用的诉求，是可调度性的前提。针对不同的业务场景，技术实现的手段不限。
腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。
主从切换
在数据库的高可用方案中，主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离，再结合智能路由选择实现无人职守的主从切换自动化，无疑是架构设计对DBA最好的馈赠。
柔性可用
“先扛住再优化”是腾讯海量运营思想之一，也为我们在做业务架构的高可用设计点明了方向。
如何在业务量突增的情况下，最大程度的保障业务可用？是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关，或者在架构中内置自动拒绝超额请求的逻辑，能够在关键时刻保证后端服务不雪崩，确保业务架构的高可用。
要点五：质量监控
保障和提高业务质量是运维努力追逐的目标，而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持，要求实现以下几点：
指标度量
每个架构都必须能被指标度量，同时，我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控，监控指标的数量随之会成倍增长。因此，架构的指标度量，我们希望的是最好只有唯一的指标度量。
基础监控
指的是网络、专线、主机、系统等低层次的指标能力，这类监控点大多属于非侵入式，很容易实现数据的采集。
在自动化运维能力健全的企业，基础监控产生的告警数据绝大部分会被收敛掉。同时，这部分监控数据将为高层次的业务监控提供数据支撑和决策依据，或者被包装成更贴近上层应用场景的业务监控数据使用，如容量、多维指标等。
组件监控
腾讯习惯把开发框架、路由服务、中间件等都统称为组件，这类监控介于基础监控和业务监控之间，运维常寄希望于在组件中内嵌监控逻辑，通过组件的推广，让组件监控的覆盖度提高，获取数据的成本属中等。如利用路由组件的监控，运维可以获得每个路由服务的请求量、延时等状态和质量指标。
业务监控
业务监控的实现方法分主动和被动的监控，即可侵入式实现，又能以旁路的方式达到目的。这类监控方案要求开发的配合，与编码和架构相关。
通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多，有日志监控、流数据监控、波测等等，业务监控属于高层次的监控，往往能直接反馈业务问题，但倘若要深入分析出问题的根源，就必须结合必要的运维监控管理规范，如返回码定义、日志协议等。需要业务架构在设计时，前置考虑运维监控管理的诉求，全局规划好的范畴。
全链路监控
基础、组件、业务的监控手段更多的是聚焦于点的监控，在分布式架构的业务场景中，要做好监控，我们必须要考虑到服务请求链路的监控。
基于唯一的交易ID或RPC的调用关系，通过技术手段还原调用关系链，再通过模型或事件触发监控告警，来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用，同样需要业务架构规划时做好前置规划和代码埋点。。
质量考核
任何监控能力的推进，质量的优化，都需要有管理的闭环，考核是一个不错的手段，从监控覆盖率、指标全面性、事件管理机制到报表考核打分，运维和开发可以携手打造一个持续反馈的质量管理闭环，让业务架构能够不断进化提升。
要点六：性能成本
在腾讯，所有的技术运营人员都肩负着一个重要的职能，就是要确保业务运营成本的合理。为此，我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。
吞吐性能
DevOps持续交付方法论中，在测试阶段进行的非功能需求测试，其中很重要一点便是对架构吞吐性能的压测，并以此确保应用上线后业务容量的健康。
在腾讯的实践中，不仅限于测试阶段会做性能压测，我们会结合路由组件的功能，对业务模块、业务SET进行真实请求的压测，以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求，利用不同业务间性能数据的对比，来推动架构性能的不断提高。
容量规划
英文capacity一词可以翻译成：应用性能、服务容量、业务总请求量，运维的容量规划是指在应用性能达标的前提下，基于业务总请求量的合理的服务容量规划。
运营成本
减少运营成本，是为公司减少现金流的投入，对企业的价值丝毫不弱于质量与效率的提升。
腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主，每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本，常常会涉及到产品功能和业务架构的优化。因此，运维理想的业务架构设计需要有足够的成本意识，
小结
本文纯属个人以运维视角整理的对微服务架构设计的一些愚见，要实现运维价值最大化，要确保业务质量、效率、成本的全面提高，业务架构这块硬骨头是不得不啃的。
运维人需要有架构意识，能站在不同角度对业务架构提出建议或需求，这也是DevOps 精神所提倡的，开发和运维联手，持续优化出最好的业务架构。