【编者的话】本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
#基本概念

在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：
##分布式

系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上。
##高可用

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。
##集群

一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。
##负载均衡

请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的。
##正向代理和反向代理

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
#架构演进

##单机架构


以淘宝作为例子。在网站最初时，应用数量与用户数都较少，可以把Tomcat和数据库部署在同一台服务器上。浏览器往www.taobao.com发起请求时，首先经过DNS服务器（域名系统）把域名转换为实际IP地址10.102.4.1，浏览器转而访问该IP对应的Tomcat。如果你想和更多Tomcat技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务
##第一次演进：Tomcat与数据库分开部署


Tomcat和数据库分别独占服务器资源，显著提高两者各自性能。

随着用户数的增长，并发读写数据库成为瓶颈
##第二次演进：引入本地缓存和分布式缓存


在Tomcat同服务器上或同JVM中增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。其中涉及的技术包括：使用memcached作为本地缓存，使用Redis作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢
##第三次演进：引入反向代理实现负载均衡


在多台服务器上分别部署Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每个Tomcat中。此处假设Tomcat最多支持100个并发，Nginx最多支持50000个并发，那么理论上Nginx把请求分发到500个Tomcat上，就能抗住50000个并发。其中涉及的技术包括：Nginx、HAProxy，两者都是工作在网络第七层的反向代理软件，主要支持http协议，还会涉及session共享、文件上传下载的问题。

反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈
##第四次演进：数据库读写分离


把数据库划分为读库和写库，读库可以有多个，通过同步机制把写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过缓存获得最新数据。其中涉及的技术包括：Mycat，它是数据库中间件，可通过它来组织数据库的分离读写和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能
##第五次演进：数据库按业务分库


把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业务，可以部署更多的服务器来支撑。这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本文讨论的重点，有兴趣的可以自行搜索解决方案。

随着用户数的增长，单机的写库会逐渐会达到性能瓶颈
##第六次演进：把大表拆分为小表


比如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。

这种做法显著的增加了数据库运维的难度，对DBA的要求较高。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的一类实现。

目前开源和商用都已经有不少MPP数据库，开源中比较流行的有Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、睿帆科技的雪球DB、华为的LibrA等等，不同的MPP数据库的侧重点也不一样，如TiDB更侧重于分布式OLTP场景，Greenplum更侧重于分布式OLAP场景，这些MPP数据库基本都提供了类似Postgresql、Oracle、MySQL那样的SQL标准支持能力，能把一个查询解析为分布式的执行计划分发到每台机器上并行执行，最终由数据库本身汇总数据进行返回，也提供了诸如权限管理、分库分表、事务、数据副本等能力，并且大多能够支持100个节点以上的集群，大大降低了数据库运维的成本，并且使数据库也能够实现水平扩展。

数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈
##第七次演进：使用LVS或F5来使多个Nginx负载均衡


由于瓶颈在Nginx，因此无法通过两层的Nginx来实现多个Nginx的负载均衡。图中的LVS和F5是工作在网络第四层的负载均衡解决方案，其中LVS是软件，运行在操作系统内核态，可对TCP请求或更高层级的网络协议进行转发，因此支持的协议更丰富，并且性能也远高于Nginx，可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件，与LVS提供的能力类似，性能比LVS更高，但价格昂贵。由于LVS是单机版的软件，若LVS所在服务器宕机则会导致整个后端系统都无法访问，因此需要有备用节点。可使用keepalived软件模拟出虚拟IP，然后把虚拟IP绑定到多台LVS服务器上，浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器，当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，把虚拟IP重定向到另外一台正常的LVS服务器，从而达到LVS服务器高可用的效果。

此处需要注意的是，上图中从Nginx层到Tomcat层这样画并不代表全部Nginx都转发请求到全部的Tomcat，在实际使用时，可能会是几个Nginx下面接一部分的Tomcat，这些Nginx之间通过keepalived实现高可用，其他的Nginx接另外的Tomcat，这样可接入的Tomcat数量就能成倍的增加。

由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同
##第八次演进：通过DNS轮询实现机房间的负载均衡


在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求
##第九次演进：引入NoSQL数据库和搜索引擎等技术


当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。

当然，引入更多组件同时会提高系统的复杂度，不同的组件保存的数据需要同步，需要考虑一致性的问题，需要有更多的运维手段来管理这些组件等。

引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难
##第十次演进：大应用拆分为小应用


按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心Zookeeper来解决。

不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级
##第十一次演进：复用的功能抽离成微服务


如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱
##第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异


通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。个人理解，微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。

业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难。
##第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理


目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes（K8S），应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。

在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在3.14节之前，服务运行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被破坏）。

使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低
##第十四次演进：以云平台承载系统


系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：

* IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
* PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
* SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论。
#架构设计总结

##架构的调整是否必须按照上述演变路径进行？

不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
##对于将要实施的系统，架构应该设计到什么程度？

对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
##服务端架构和大数据架构有什么区别？

所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。
#有没有一些架构设计的原则？


* N+1设计。系统中的每个组件都应做到没有单点故障；
* 回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
* 禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
* 监控设计。在设计阶段就要考虑监控的手段；
* 多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
* 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
* 资源隔离设计。应避免单一业务占用全部资源；
* 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
* 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
* 使用商用硬件。商用硬件能有效降低硬件故障的机率；
* 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
* 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

原文链接：https://segmentfault.com/a/1190000018626163

Kubedog 是一个开源的 Golang 项目，使用 watch 方式对 Kubernetes 资源进行跟踪，能够方便的用于日常运维和 CI/CD 过程之中，项目中除了一个 CLI 小工具之外，还提供了一组 SDK，用户可以将其中的 Watch 功能集成到自己的系统之中。安装过程非常简单，在项目网页直接下载即可。如果你想和更多Kubernetes技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

Kubedog CLI 有两个功能：rollout track 和 follow。
#rollout track
在 Kubernetes 上运行应用时，通常的做法是使用 kubectl apply 提交 YAML 之后，使用 kubectl get -w 或者 watch kubectl get 之类的命令等待 Pod 启动。如果启动成功，则进行测试等后续动作；如果启动失败，就需要用 kubectl logs、kubectl describe 等命令来查看失败原因。kubedog 能在一定程度上简化这一过程。

例如使用 kubectl run 命令创建一个新的 Deployment 资源，并使用 kubedog 跟进创建进程：

$ kubectl run nginx --image=nginx22

...

deployment.apps/nginx created



$ kubedog rollout track deployment nginx

 # deploy/nginx added

 # deploy/nginx rs/nginx-6cc78cbf64 added

 # deploy/nginx po/nginx-6cc78cbf64-8pnjz added

 # deploy/nginx po/nginx-6cc78cbf64-8pnjz nginx error: ImagePullBackOff: Back-off pulling image "nginx22"

deploy/nginx po/nginx-6cc78cbf64-8pnjz nginx failed: ImagePullBackOff: Back-off pulling image "nginx22"



$ echo $?

130

很方便的看出，运行失败的状态及其原因，并且可以使用返回码来进行判断，方便在 Pipeline 中的运行。接下来可以使用 kubectl edit 命令编辑 Deployment，修改正确的镜像名称。然后再次进行验证：

$ kubectl edit deployment nginx

deployment.extensions/nginx edited

$ kubedog rollout track deployment nginx

 # deploy/nginx added

 # deploy/nginx rs/nginx-dbddb74b8 added

 # deploy/nginx po/nginx-dbddb74b8-x4nkm added

 # deploy/nginx event: po/nginx-dbddb74b8-x4nkm Pulled: Successfully pulled image "nginx"

 # deploy/nginx event: po/nginx-dbddb74b8-x4nkm Created: Created container

 # deploy/nginx event: po/nginx-dbddb74b8-x4nkm Started: Started container

 # deploy/nginx event: ScalingReplicaSet: Scaled down replica set nginx-6cc78cbf64 to 0

 # deploy/nginx become READY

$ echo $?

0 

修改完成，重新运行 kubedog，会看到成功运行的情况，并且返回值也变成了 0。
#follow
follow 命令的功能和 kubetail 的功能有少量重叠，可以用 Deployment/Job/Daemonset 等为单位，查看其中所有 Pod 的日志，例如前面用的 Nginx，如果有访问的话，就会看到如下结果：

$ kubedog follow deployment nginx

 # deploy/nginx appears to be ready

 # deploy/nginx rs/nginx-6cc78cbf64 added

 # deploy/nginx new rs/nginx-dbddb74b8 added

 # deploy/nginx rs/nginx-dbddb74b8(new) po/nginx-dbddb74b8-x4nkm added

 # deploy/nginx rs/nginx-6cc54845d9 added

 # deploy/nginx event: ScalingReplicaSet: Scaled up replica set nginx-6cc54845d9 to 1

 # deploy/nginx rs/nginx-6cc54845d9(new) po/nginx-6cc54845d9-nhlvs added

 # deploy/nginx event: po/nginx-6cc54845d9-nhlvs Pulling: pulling image "nginx:alpine"

 # deploy/nginx event: po/nginx-6cc54845d9-nhlvs Pulled: Successfully pulled image "nginx:alpine"

 # deploy/nginx event: po/nginx-6cc54845d9-nhlvs Created: Created container

 # deploy/nginx event: po/nginx-6cc54845d9-nhlvs Started: Started container

 # deploy/nginx event: ScalingReplicaSet: Scaled down replica set nginx-dbddb74b8 to 0

 # deploy/nginx become READY

 # deploy/nginx event: po/nginx-dbddb74b8-x4nkm Killing: Killing container with id docker://nginx:Need to kill Pod

[quote]> deploy/nginx rs/nginx-dbddb74b8 po/nginx-dbddb74b8-x4nkm nginx[/quote]



[quote]> deploy/nginx rs/nginx-6cc54845d9(new) po/nginx-6cc54845d9-nhlvs nginx

127.0.0.1 - - [02/Jun/2019:11:35:08 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget" "-"

127.0.0.1 - - [02/Jun/2019:11:35:11 +0000] "GET / HTTP/1.1" 200 612 "-" "Wget" "-"

项目地址
https://github.com/flant/kubedog[/quote]

原文链接：https://blog.fleeto.us/post/intro-kubedog/

#什么是ZooKeeper

ZooKeeper是一个分布式开源框架，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务——分布式同步（Distributed Synchronization）、命名服务（Naming Service）、集群维护（Group Maintenance）等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。ZooKeeper本身可以以单机模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。
#Zookeeper简介

1. ZooKeeper是为别的分布式程序服务的
2. ZooKeeper本身就是一个分布式程序（只要有半数以上节点存活，ZooKeeper就能正常服务）
3. ZooKeeper所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统> 一名称服务等
4. 虽然说可以提供各种服务，但是ZooKeeper在底层其实只提供了两个功能：

1. 管理（存储，读取）用户程序提交的数据（类似namenode中存放的metadata）
2. 为用户程序提供数据节点监听服务

#ZooKeeper应用场景图



#ZooKeeper集群机制

ZooKeeper集群的角色： Leader 和 follower

只要集群中有半数以上节点存活，集群就能提供服务。
#ZooKeeper特性

1. ZooKeeper：一个leader，多个follower组成的集群
2. 全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
3. 分布式读写，更新请求转发，由leader实施
4. 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
5. 数据更新原子性，一次数据更新要么成功，要么失败
6. 实时性，在一定时间范围内，client能读到最新数据

#ZooKeeper的数据存储机制

##数据存储形式

ZooKeeper中对用户的数据采用kv形式存储。如果你想和更多ZooKeeper技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

只是ZooKeeper有点特别：

key：是以路径的形式表示的，那就以为着，各key之间有父子关系，比如：

* / 是顶层key
* 用户建的key只能在/ 下作为子节点，比如建一个key： /aa 这个key可以带value数据
* 也可以建一个key： /bb
* 也可以建key： /aa/xx

ZooKeeper中，对每一个数据key，称作一个znode

综上所述，ZooKeeper中的数据存储形式如下：

##znode类型

ZooKeeper中的znode有多种类型：

1. PERSISTENT 持久的：创建者就算跟集群断开联系，该类节点也会持久存在与zk集群中
2. EPHEMERAL 短暂的：创建者一旦跟集群断开联系，zk就会将这个节点删除
3. SEQUENTIAL 带序号的：这类节点，zk会自动拼接上一个序号，而且序号是递增的

组合类型：

* PERSISTENT ：持久不带序号
* EPHEMERAL ：短暂不带序号
* PERSISTENT 且 SEQUENTIAL ：持久且带序号
* EPHEMERAL 且 SEQUENTIAL ：短暂且带序号

#ZooKeeper的集群部署

集群选举示意图：

解压ZooKeeper安装包到apps目录下：

tar -zxvf zookeeper-3.4.6.tar.gz -C apps



cd /root/apps/zookeeper-3.4.6/conf

cp zoo_sample.cfg zoo.cfg

vi zoo.cfg

修改dataDir=/root/zkdata

在后面加上集群的机器:2888是leader和follower通讯端口，3888是投票的

server.1=hdp-01:2888:3888

server.2=hdp-02:2888:3888

server.3=hdp-03:2888:3888

对3台节点，都创建目录 mkdir /root/zkdata

对3台节点，在工作目录中生成myid文件，但内容要分别为各自的id： 1,2,3

echo 1 > /root/zkdata/myid

echo 2 > /root/zkdata/myid

echo 3 > /root/zkdata/myid

从hdp20-01上scp安装目录到其他两个节点

cd apps

scp -r zookeeper-3.4.6/ hdp-02:$PWD

scp -r zookeeper-3.4.6/ hdp-03:$PWD

启动ZooKeeper集群

ZooKeeper没有提供自动批量启动脚本，需要手动一台一台地起ZooKeeper进程

在每一台节点上，运行命令：

cd /root/apps/zookeeper-3.4.6

bin/zkServer.sh start

启动后，用jps应该能看到一个进程：QuorumPeerMain

但是，光有进程不代表zk已经正常服务，需要用命令检查状态：

bin/zkServer.sh status

能看到角色模式：为leader或follower，即正常了。

自己写个脚本，一键启动

vi zkmanage.sh



 #!/bin/bash

for host in hdp-01 hdp-02 hdp-03

do

echo "${host}:$1ing....."

ssh $host "/root/apps/zookeeper-3.4.6/bin/zkServer.sh $1"

done

停止命令：sh zjmanage.sh stop

加个可执行权限：chmod +zkmanage.sh

启动命令：./zkmanage.sh start

但是出现没有Java环境变量问题，修改配置文件

vi zkmanage.sh

修改配置如下：

#!/bin/bash

for host in hdp-01 hdp-02 hdp-03

do

echo "${host}:$1ing....."

ssh $host "source /etc/profile;/root/apps/zookeeper-3.4.6/bin/zkServer.sh $1"

done



sleep 2

for host in hdp-01 hdp-02 hdp-03

do

ssh $host "source /etc/profile;/root/apps/zookeeper-3.4.6/bin/zkServer.sh status"

done

启动集群结果：

hdp-01:starting.....

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Starting zookeeper ... STARTED

hdp-02:starting.....

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Starting zookeeper ... STARTED

hdp-03:starting.....

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Starting zookeeper ... STARTED

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Mode: follower

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Mode: leader

JMX enabled by default

Using config: /root/apps/zookeeper-3.4.6/bin/../conf/zoo.cfg

Mode: follower

ZooKeeper的Java客户端操作代码：

public class ZookeeperCliDemo {

    ZooKeeper zk =null;

    @Before

    public void init() throws Exception {

       zk=new ZooKeeper("hdp-01:2181,hdp-02:2181,hdp-03:2181", 2000, null);

    }

    @Test

    public void testCreate() throws Exception {

        //参数1：要创建的节点路径；参数2：数据；参数3：访问权限；参数4：节点类型

        String create = zk.create("/eclipse", "hello eclipse".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

        System.out.println(create);

        zk.close();

    }



    @Test

    public void testUpdate() throws Exception {

        //参数1：节点路径；参数2：数据；参数3：所要修改的版本，-1表示任意版本

        zk.setData("/eclipse","我喜欢青青".getBytes(),-1);

        zk.close();

    }

   @Test

    public void testGet() throws Exception {

       //参数1：节点路径；参数2：事件监听；参数3：所要修改的版本，null表示最新版本

        byte[] data = zk.getData("/eclipse", false, null);

        System.out.println(new String(data,"UTF-8"));

        zk.close();

    }



    @Test

    public void testListChildren() throws KeeperException, InterruptedException {

        //参数1：节点路径；参数2：是否要监听

        //注意：返回的结果只有子节点的名字，不带全路径

        List children = zk.getChildren("/cc", false);

        for(String child:children){

            System.out.println(child);

        }

        zk.close();

    }



    @Test

    public void testRm() throws KeeperException, InterruptedException {

        zk.delete("/eclipse",-1);

        zk.close();

    }

} 

ZooKeeper监听功能代码：

public class ZookeeperWatchDemo {

    ZooKeeper zk =null;

    @Before

    public void init() throws Exception {

        zk=new ZooKeeper("hdp-01:2181,hdp-02:2181,hdp-03:2181", 2000,  new Watcher() {

            public void process(WatchedEvent watchedEvent) {

                if (watchedEvent.getState() == Event.KeeperState.SyncConnected

                        && watchedEvent.getType() == Event.EventType.NodeDataChanged) {

                    System.out.println("收到事件所发生节点的路径" + watchedEvent.getPath());

                    System.out.println("收到事件所发生节点的状态" + watchedEvent.getState());

                    System.out.println("收到事件所发生节点的类型" + watchedEvent.getType());

                    System.out.println("watch事件通知。。换照片");

                    try {

                        zk.getData("/mygirls", true, null);

                    } catch (Exception e) {

                        e.printStackTrace();

                    }

                }else if(watchedEvent.getState()==Event.KeeperState.SyncConnected &&

                        watchedEvent.getType()==Event.EventType.NodeChildrenChanged){

                    System.out.println("收到事件所发生节点的路径" + watchedEvent.getPath());

                    System.out.println("收到事件所发生节点的状态" + watchedEvent.getState());

                    System.out.println("收到事件所发生节点的类型" + watchedEvent.getType());



                }

            }

        });

    }



    @Test

    public void testGetWatch() throws Exception {

        byte[] data = zk.getData("/mygirls",true, null);

        List children = zk.getChildren("/mygirls", true);

        System.out.println(new String(data,"UTF-8"));

        Thread.sleep(Long.MAX_VALUE);

    }

} 

ZooKeeper开发分布式系统案例代码，动态上下线感知。

服务代码：

public class TimeQueryServer {

    ZooKeeper zk=null;

    public void connectZk()throws Exception{

        zk=new ZooKeeper("hdp-01:2181,hdp-02:2181,hdp-03:2181", 2000, null);

    }



    public void registerServerInfo(String hostname,String port)throws Exception{

        /**

         * 先判断注册节点的父节点是否存在，如果不存在，则创建持久节点

         */

        Stat exists = zk.exists("/servers", false);

        if(exists==null){

            zk.create("/servers",null,ZooDefs.Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

        }

        /**

         * 注册服务器数据到zk的约定注册节点下

         */

        String create = zk.create("/servers/server", (hostname + ":" + port).getBytes(),

                ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);

        System.out.println(hostname+" 服务器向zk 注册成功，注册节点为：/servers"+create);

    }

    public static void main(String[] args) throws Exception {

        //1.构造zk连接

        TimeQueryServer timeQueryServer = new TimeQueryServer();

        timeQueryServer.connectZk();

        //2.注册服务器信息

        timeQueryServer.registerServerInfo("192.168.150.3","44772");

        //3.启动业务线程开始处理业务

        new TimeQueryService(44772).start();

    }

} 

public class TimeQueryService extends Thread {

    int port=0;

    public TimeQueryService(int port){

        this.port=port;

    }

    @Override

    public void run() {

        try {

            ServerSocket ss = new ServerSocket(port);

            System.out.println("业务线程已经绑定端口"+port+"开始接受客户端请求..");

            while (true){

                Socket sc = ss.accept();

                InputStream inputStream = sc.getInputStream();

                OutputStream outputStream = sc.getOutputStream();

                outputStream.write(new Date().toString().getBytes());

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

} 

消费者代码：

public class Consumer {



    //定义一个list用于存放在线的服务器列表

    private volatile ArrayListonlineServers=new ArrayList();

    ZooKeeper zk=null;

    public void connectZk()throws Exception{

        zk=new ZooKeeper("hdp-01:2181,hdp-02:2181,hdp-03:2181", 2000, new Watcher() {

            public void process(WatchedEvent watchedEvent) {

                if (watchedEvent.getState()==Event.KeeperState.SyncConnected && watchedEvent.getType()==Event.EventType.NodeChildrenChanged){

                    try{

                        //事件回调逻辑中，再次查询zk上在线服务器节点即可，查询逻辑中又再次注册子节点变化事件监听

                        getOnlineServers();

                    }catch (Exception e){

                        e.printStackTrace();

                    }

                }

            }

        });

    }

    //查询在线服务器列表

    public void getOnlineServers()throws Exception{

        List children = zk.getChildren("/servers", true);

        ArrayList servers = new ArrayList();

        for (String child:children){

            byte[] data = zk.getData("/servers/" + child, false, null);

            String serverInfo=new String(data);

            servers.add(serverInfo);

        }

        onlineServers=servers;

        System.out.println("查询了一次zk,当前在线的服务器有："+servers);



    }



    public void setRequest() throws Exception {

        Random random = new Random();

        while (true){

            try {

                int nextInt=random.nextInt(onlineServers.size());

                String server=onlineServers.get(nextInt);

                String hostname=server.split(":")[0];

                int port=Integer.parseInt(server.split(":")[1]);

                System.out.println("本次请求挑选的服务器为："+server);



                Socket socket = new Socket(hostname, port);

                OutputStream out = socket.getOutputStream();

                InputStream in = socket.getInputStream();

                out.write("hahaha".getBytes());

                out.flush();



                byte[] buf = new byte[256];

                int read=in.read(buf);

                String s = new String(buf, 0, read);

                System.out.println("服务器响应时间为："+s);

                out.close();

                in.close();

                socket.close();

                Thread.sleep(2000);

            }catch (Exception e){



            }



        }

    }

    public static void main(String[] args) throws Exception {

        //构造zk连接对象

        Consumer consumer = new Consumer();

        consumer.connectZk();

        //查询在线服务器列表

        consumer.getOnlineServers();

        //处理业务

        consumer.setRequest();

    }

} 

pom

        

            junit

            junit

            RELEASE

        

        

            org.apache.logging.log4j

            log4j-core

            2.8.2

        

        

        

            org.apache.zookeeper

            zookeeper

            3.4.10

        

    

启动多个服务。

控制台输出：

192.168.150.3 服务器向zk 注册成功，注册节点为：/servers/servers/server0000000018
业务线程已经绑定端口44772开始接受客户端请求..

192.168.150.3 服务器向zk 注册成功，注册节点为：/servers/servers/server0000000019
业务线程已经绑定端口44773开始接受客户端请求..

192.168.150.3 服务器向zk 注册成功，注册节点为：/servers/servers/server0000000020
业务线程已经绑定端口44774开始接受客户端请求..

消费者启动

控制台输出：

查询了一次zk，当前在线的服务器有：[192.168.150.3:44773, 192.168.150.3:44772, 192.168.150.3:44774]
本次请求挑选的服务器为：192.168.150.3:44772
服务器响应时间为：Mon Jun 03 20:03:21 CST 2019
本次请求挑选的服务器为：192.168.150.3:44773
服务器响应时间为：Mon Jun 03 20:03:23 CST 2019
本次请求挑选的服务器为：192.168.150.3:44773
服务器响应时间为：Mon Jun 03 20:03:25 CST 2019
本次请求挑选的服务器为：192.168.150.3:44772
服务器响应时间为：Mon Jun 03 20:03:27 CST 2019

下线一个服务后，控制台输出：

查询了一次zk,当前在线的服务器有：[192.168.150.3:44773, 192.168.150.3:44772]
本次请求挑选的服务器为：192.168.150.3:44773
服务器响应时间为：Mon Jun 03 20:04:19 CST 2019
本次请求挑选的服务器为：192.168.150.3:44773
服务器响应时间为：Mon Jun 03 20:04:21 CST 2019
本次请求挑选的服务器为：192.168.150.3:44773
服务器响应时间为：Mon Jun 03 20:04:23 CST 2019
本次请求挑选的服务器为：192.168.150.3:44773

原文链接：https://my.oschina.net/u/3995125/blog/3057475

【编者的话】今天和大家聊一下在采用Spring Cloud进行微服务架构设计时，微服务之间调用时异常处理机制应该如何设计的问题。我们知道在进行微服务架构设计时，一个微服务一般来说不可避免地会同时面向内部和外部提供相应的功能服务接口。面向外部提供的服务接口，会通过服务网关（如使用Zuul提供的apiGateway）面向公网提供服务，如给App客户端提供的用户登陆、注册等服务接口。

而面向内部的服务接口，则是在进行微服务拆分后由于各个微服务系统的边界划定问题所导致的功能逻辑分散，而需要微服务之间彼此提供内部调用接口，从而实现一个完整的功能逻辑，它是之前单体应用中本地代码接口调用的服务化升级拆分。例如，需要在团购系统中，从下单到完成一次支付，需要交易系统在调用订单系统完成下单后再调用支付系统，从而完成一次团购下单流程，这个时候由于交易系统、订单系统及支付系统是三个不同的微服务，所以为了完成这次用户订单，需要App调用交易系统提供的外部下单接口后，由交易系统以内部服务调用的方式再调用订单系统和支付系统，以完成整个交易流程。如下图所示：

这里需要说明的是，在基于Spring Cloud的微服务架构中，所有服务都是通过如Consul或Eureka这样的服务中间件来实现的服务注册与发现后来进行服务调用的，只是面向外部的服务接口会通过网关服务进行暴露，面向内部的服务接口则在服务网关进行屏蔽，避免直接暴露给公网。而内部微服务间的调用还是可以直接通过Consul或Eureka进行服务发现调用，这二者并不冲突，只是外部客户端是通过调用服务网关，服务网关通过Consul再具体路由到对应的微服务接口，而内部微服务则是直接通过Consul或者Eureka发现服务后直接进行调用。如果你想和更多Spring Cloud技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
#异常处理的差异

面向外部的服务接口，我们一般会将接口的报文形式以JSON的方式进行响应，除了正常的数据报文外，我们一般会在报文格式中冗余一个响应码和响应信息的字段，如正常的接口成功返回：

 {

    "code" : "0",

    "msg" : "success",

    "data" : {

        "userId" : "zhangsan",

        "balance" : 5000

    }

} 

而如果出现异常或者错误，则会相应地返回错误码和错误信息，如：

 {

    "code" : "-1",

    "msg" : "请求参数错误",

    "data" : null

} 

在编写面向外部的服务接口时，服务端所有的异常处理我们都要进行相应地捕获，并在controller层映射成相应地错误码和错误信息，因为面向外部的是直接暴露给用户的，是需要进行比较友好的展示和提示的，即便系统出现了异常也要坚决向用户进行友好输出，千万不能输出代码级别的异常信息，否则用户会一头雾水。对于客户端而言，只需要按照约定的报文格式进行报文解析及逻辑处理即可，一般我们在开发中调用的第三方开放服务接口也都会进行类似的设计，错误码及错误信息分类得也是非常清晰！

而微服务间彼此的调用在异常处理方面，我们则是希望更直截了当一些，就像调用本地接口一样方便，在基于Spring Cloud的微服务体系中，微服务提供方会提供相应的客户端SDK代码，而客户端SDK代码则是通过FeignClient的方式进行服务调用，如：而微服务间彼此的调用在异常处理方面，我们则是希望更直截了当一些，就像调用本地接口一样方便，在基于Spring Cloud的微服务体系中，微服务提供方会提供相应的客户端SDK代码，而客户端SDK代码则是通过FeignClient的方式进行服务调用，如：

@FeignClient( value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class )

public interface OrderClient {

    /[i] 订单(内) [/i]/

    @RequestMapping( value = "/order/createOrder", method = RequestMethod.POST )

    OrderCostDetailVo orderCost( @RequestParam(value = "orderId") String orderId,

                     @RequestParam(value = "userId") long userId,

                     @RequestParam(value = "orderType") String orderType,

                     @RequestParam(value = "orderCost") int orderCost,

                     @RequestParam(value = "currency") String currency,

                     @RequestParam(value = "tradeTime") String tradeTime )

} 

而服务的调用方在拿到这样的SDK后就可以忽略具体的调用细节，实现像本地接口一样调用其他微服务的内部接口了，当然这个是FeignClient框架提供的功能，它内部会集成像Ribbon和Hystrix这样的框架来实现客户端服务调用的负载均衡和服务熔断功能（注解上会指定熔断触发后的处理代码类），由于本文的主题是讨论异常处理，这里暂时就不作展开了。

现在的问题是，虽然FeignClient向服务调用方提供了类似于本地代码调用的服务对接体验，但服务调用方却是不希望调用时发生错误的，即便发生错误，如何进行错误处理也是服务调用方希望知道的事情。另一方面，我们在设计内部接口时，又不希望将报文形式搞得类似于外部接口那样复杂，因为大多数场景下，我们是希望服务的调用方可以直截了的获取到数据，从而直接利用FeignClient客户端的封装，将其转化为本地对象使用。

@Data

@Builder

public class OrderCostDetailVo implements Serializable {

    private String  orderId;

    private String  userId;

    private int status; /[i] 1:欠费状态；2:扣费成功 [/i]/

    private int orderCost;

    private String  currency;

    private int payCost;

    private int oweCost;

    public OrderCostDetailVo( String orderId, String userId, int status, int orderCost, String currency, int payCost,

                  int oweCost )

    {

        this.orderId    = orderId;

        this.userId = userId;

        this.status = status;

        this.orderCost  = orderCost;

        this.currency   = currency;

        this.payCost    = payCost;

        this.oweCost    = oweCost;

    }

} 

如我们在把返回数据就是设计成了一个正常的VO/BO对象的这种形式，而不是向外部接口那么样额外设计错误码或者错误信息之类的字段，当然，也并不是说那样的设计方式不可以，只是感觉会让内部正常的逻辑调用，变得比较啰嗦和冗余，毕竟对于内部微服务调用来说，要么对，要么错，错了就Fallback逻辑就好了。

不过，话虽说如此，可毕竟服务是不可避免的会有异常情况的。如果内部服务在调用时发生了错误，调用方还是应该知道具体的错误信息的，只是这种错误信息的提示需要以异常的方式被集成了FeignClient的服务调用方捕获，并且不影响正常逻辑下的返回对象设计，也就是说我不想额外在每个对象中都增加两个冗余的错误信息字段，因为这样看起来不是那么优雅！

既然如此，那么应该如何设计呢？
#最佳实践设计

首先，无论是内部还是外部的微服务，在服务端我们都应该设计一个全局异常处理类，用来统一封装系统在抛出异常时面向调用方的返回信息。而实现这样一个机制，我们可以利用Spring提供的注解@ControllerAdvice来实现异常的全局拦截和统一处理功能。如：

@Slf4j

@RestController

@ControllerAdvice

public class GlobalExceptionHandler {

    @Resource

    MessageSource messageSource;

    @ExceptionHandler( { org.springframework.web.bind.MissingServletRequestParameterException.class } )

    @ResponseBody

    public APIResponse processRequestParameterException( HttpServletRequest request,

                                 HttpServletResponse response,

                                 MissingServletRequestParameterException e )

    {

        response.setStatus( HttpStatus.FORBIDDEN.value() );

        response.setContentType( "application/json;charset=UTF-8" );

        APIResponse result = new APIResponse();

        result.setCode( ApiResultStatus.BAD_REQUEST.getApiResultStatus() );

        result.setMessage(

            messageSource.getMessage( ApiResultStatus.BAD_REQUEST.getMessageResourceName(),

                          null, LocaleContextHolder.getLocale() ) + e.getParameterName() );

        return(result);

    }



    @ExceptionHandler( Exception.class )

    @ResponseBody

    public APIResponse processDefaultException( HttpServletResponse response,

                            Exception e )

    {

        /[i] log.error("Server exception", e); [/i]/

        response.setStatus( HttpStatus.INTERNAL_SERVER_ERROR.value() );

        response.setContentType( "application/json;charset=UTF-8" );

        APIResponse result = new APIResponse();

        result.setCode( ApiResultStatus.INTERNAL_SERVER_ERROR.getApiResultStatus() );

        result.setMessage( messageSource.getMessage( ApiResultStatus.INTERNAL_SERVER_ERROR.getMessageResourceName(), null,

                                 LocaleContextHolder.getLocale() ) );

        return(result);

    }



    @ExceptionHandler( ApiException.class )

    @ResponseBody

    public APIResponse processApiException( HttpServletResponse response,

                        ApiException e )

    {

        APIResponse result = new APIResponse();

        response.setStatus( e.getApiResultStatus().getHttpStatus() );

        response.setContentType( "application/json;charset=UTF-8" );

        result.setCode( e.getApiResultStatus().getApiResultStatus() );

        String message = messageSource.getMessage( e.getApiResultStatus().getMessageResourceName(),

                               null, LocaleContextHolder.getLocale() );

        result.setMessage( message );

        /[i] log.error("Knowned exception", e.getMessage(), e); [/i]/

        return(result);

    }



    /**

     * 内部微服务异常统一处理方法

     */

    @ExceptionHandler( InternalApiException.class )

    @ResponseBody

    public APIResponse processMicroServiceException( HttpServletResponse response,

                             InternalApiException e )

    {

        response.setStatus( HttpStatus.OK.value() );

        response.setContentType( "application/json;charset=UTF-8" );

        APIResponse result = new APIResponse();

        result.setCode( e.getCode() );

        result.setMessage( e.getMessage() );

        return(result);

    }

} 

如上述代码，我们在全局异常中针对内部统一异常及外部统一异常分别作了全局处理，这样只要服务接口抛出了这样的异常就会被全局处理类进行拦截并统一处理错误的返回信息。

理论上我们可以在这个全局异常处理类中，捕获处理服务接口业务层抛出的所有异常并统一响应，只是那样会让全局异常处理类变得非常臃肿，所以从最佳实践上考虑，我们一般会为内部和外部接口分别设计一个统一面向调用方的异常对象，如外部统一接口异常我们叫ApiException，而内部统一接口异常叫InternalApiException。这样，我们就需要在面向外部的服务接口controller层中，将所有的业务异常转换为ApiException；而在面向内部服务的controller层中将所有的业务异常转化为InternalApiException。如：

@RequestMapping( value = "/creatOrder", method = RequestMethod.POST )

public OrderCostDetailVo orderCost(

    @RequestParam(value = "orderId") String orderId,

    @RequestParam(value = "userId") long userId,

    @RequestParam(value = "orderType") String orderType,

    @RequestParam(value = "orderCost") int orderCost,

    @RequestParam(value = "currency") String currency,

    @RequestParam(value = "tradeTime") String tradeTime ) throws InternalApiException

{

    OrderCostVo costVo = OrderCostVo.builder().orderId( orderId ).userId( userId ).busiId( busiId ).orderType( orderType )

                 .duration( duration ).bikeType( bikeType ).bikeNo( bikeNo ).cityId( cityId ).orderCost( orderCost )

                 .currency( currency ).strategyId( strategyId ).tradeTime( tradeTime ).countryName( countryName )

                 .build();

    OrderCostDetailVo orderCostDetailVo;

    try {

        orderCostDetailVo = orderCostServiceImpl.orderCost( costVo );

        return(orderCostDetailVo);

    } catch ( VerifyDataException e ) {

        log.error( e.toString() );

        throw new InternalApiException( e.getCode(), e.getMessage() );

    } catch ( RepeatDeductException e ) {

        log.error( e.toString() );

        throw new InternalApiException( e.getCode(), e.getMessage() );

    }

} 

如上面的内部服务接口的controller层中将所有的业务异常类型都统一转换成了内部服务统一异常对象InternalApiException了。这样全局异常处理类，就可以针对这个异常进行统一响应处理了。

对于外部服务调用方的处理就不多说了。而对于内部服务调用方而言，为了能够更加优雅和方便地实现异常处理，我们也需要在基于FeignClient的SDK代码中抛出统一内部服务异常对象，如：

@FeignClient( value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class )

public interface OrderClient {

    /[i] 订单(内) [/i]/

    @RequestMapping( value = "/order/createOrder", method = RequestMethod.POST )

    OrderCostDetailVo orderCost( @RequestParam(value = "orderId") String orderId,

                     @RequestParam(value = "userId") long userId,

                     @RequestParam(value = "orderType") String orderType,

                     @RequestParam(value = "orderCost") int orderCost,

                     @RequestParam(value = "currency") String currency,

                     @RequestParam(value = "tradeTime") String tradeTime ) throws InternalApiException

};

这样在调用方进行调用时，就会强制要求调用方捕获这个异常，在正常情况下调用方不需要理会这个异常，像本地调用一样处理返回对象数据就可以了。在异常情况下，则会捕获到这个异常的信息，而这个异常信息则一般在服务端全局处理类中会被设计成一个带有错误码和错误信息的json数据，为了避免客户端额外编写这样的解析代码，FeignClient为我们提供了异常解码机制。如：

@Slf4j

@Configuration

public class FeignClientErrorDecoder implements feign.codec.ErrorDecoder {

    private static final Gson gson = new Gson();

    @Override

    public Exception decode( String methodKey, Response response )

    {

        if ( response.status() != HttpStatus.OK.value() )

        {

            if ( response.status() == HttpStatus.SERVICE_UNAVAILABLE.value() )

            {

                String errorContent;

                try {

                    errorContent = Util.toString( response.body().asReader() );

                    InternalApiException internalApiException = gson.fromJson( errorContent, InternalApiException.class );

                    return(internalApiException);

                } catch ( IOException e ) {

                    log.error( "handle error exception" );

                    return(new InternalApiException( 500, "unknown error" ) );

                }

            }

        }

        return(new InternalApiException( 500, "unknown error" ) );

    }

} 

我们只需要在服务调用方增加这样一个FeignClient解码器，就可以在解码器中完成错误消息的转换。这样，我们在通过FeignClient调用微服务时就可以直接捕获到异常对象，从而实现向本地一样处理远程服务返回的异常对象了。

以上就是在利用Spring Cloud进行微服务拆分后关于异常处理机制的一点分享了，如有更好的方式，也欢迎大家给我留言！

作者：若丨寒
链接：https://www.jianshu.com/p/9fb7684bbeca

【编者的话】最近接手的代码中遇到几个缓存的问题，存在一些设计原则的问题，这里总结一下，希望可以对你有帮助。
#问题

问题1： 店铺数据的获取，将用户关注的数据放在店铺信息一起返回。

对外提供的接口：

List getPageShop(final Query query,final Boolean cache);

返回的店铺信息：

public class Shop {



    public static final long DEFAULT_PRIORITY = 10L;



    /**

     * 唯一标识

     */

    private Long id;

   //省略了店铺其他信息

    /**

     * 用户关注

     */

    private ShopAttention attention;

} 

当调用方设置cache为true时，因为有缓存的存在，获取不到用户是否关注的数据。

问题2： 统计店铺的被关注数导致的慢SQL,导致数据库cpu飙高，影响到了整个应用。

SQL：

SELECT shop_id, count(user_Id) as attentionNumber

FROM shop_attention

WHERE shop_id IN



    #{shopId}



GROUP BY shopId

这两种代码的写法都是基于一个基准。

不同的地方的缓存策略不一样，比如我更新的地方，查找数据时不能缓存，页面展示的查找的地方需要缓存。 既然服务提供方不知道该不该缓存，那就不管了，交给调用方去管理。如果你想和更多微服务技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

这种假设本身没什么问题，但是忽略了另外一个原则，服务的内聚性。不应该被外部知道的就没必要暴露给外部。

无论是面向过程的C，还是面向对象的语言，都强调内聚性，也就是高内聚，低耦合。单体应用中应当遵循这个原则，微服务同样遵循这个原则。但是在实际过程中，我们发现做到高内聚并不简单。我们必须要时时刻刻审视方法/服务的边界，只有确定好职责边界，才能写出高内聚的代码。
#问题分析

第一个问题，从缓存的角度来看，是忽略了数据的更新频繁性以及数据获取的不同场景。

对于店铺这样一个大的聚合根，本身包含的信息很多，有些数据可能会被频繁更改的，有些则会很少更新的。那么不同的修改频率，是否缓存/缓存策略自然不同，使用同一个参数Boolean cache来控制显然不妥

第二个问题，这种统计类的需求使用SQL统计是一种在数据量比较小的情况下的权宜之计，当数据规模增大后，必须要使用离线计算或者流式计算来解决。它本身是一个慢SQL，所以必须要控制号调用量，这种统计的数据量的时效性应该由服务方控制，不需要暴露给调用方。否则就会出现上述的问题，调用方并不清楚其中的逻辑，不走缓存的话就会使得调用次数增加，QPS的增加会导致慢SQL打垮数据库。
#解法

缓存更新本身就是一个难解的问题，在微服务化后，多个服务就更加复杂了。涉及到跨服务的多级缓存一致性的问题。

所以对大部分的业务，我们可以遵循这样的原则来简单有效处理。

对数据的有效性比较敏感的调用都收敛到服务内部（领域内部应该更合适），不要暴露给调用方。

领域内部做数据的缓存失效控制。

缓存预计算（有些页面的地方不希望首次打开慢）的逻辑也应该放在领域内控制，不要暴露给调用方。

在领域内部控制在不同的地方使用不同的缓存策略，比如更新数据的地方需要获取及时的数据。比如商品的价格，和商品的所属类目更新频次不同，需要有不同的过期时间。

跨服务调用为了减少rpc调用，可以再进行一层缓存。因为这些调用可以接受过期的数据，再进行一层缓存没问题，expired time叠加也没多大影响（expire time在这边主要是影响缓存的命中数）

以上述店铺查询问题改造为例

扩展：如果后续有case在跨服务的调用时，对数据的过期比较敏感，并且在调用方也做了缓存，那就是跨服务的多级缓存一致性的问题。那就需要服务方告知调用方缓存何时失效，使用消息队列or其他方式来实现。

作者：方丈的寺院
原文：https://fangzhang.blog.csdn.net/article/details/89892575

【编者的话】在基于容器的Node.js应用程序中管理内存的最佳实践。

在docker容器中运行Node.js应用程序时，传统的内存参数调整并不总是按预期工作。本文我们将阐述在基于容器的Node.js应用程序内存参数调优中并不总是有效的原因，并提供了在容器环境中使用Node.js应用程序时可以遵循的建议和最佳实践。
#综述
当Node.js应用程序运行在设置了内存限制的容器中时（使用docker --memory选项或者系统中的其他任意标志），请使用--max-old-space-size选项以确保Node.js知道其内存限制并且设置其值小于容器限制。

当Node.js应用程序在容器内运行时，将Node.js应用程序的峰值内存值设置为容器的内存容量（假如容器内存可以调整的话）。

接下来让我们更详细地探讨一下。
#Docker内存限制
默认情况下，容器是没有资源限制的，可以使用系统（OS）允许的尽可能多的可用内存资源。但是docker 运行命令可以指定选项，用于设置容器可以使用的内存或CPU。

该docker-run命令如下所示：docker run --memory --interactive --tty bash。

参数介绍：

* x是以y为单位的内存
* y可以是b（字节），k（千字节），m（兆字节），g（千兆字节）

例如：docker run --memory 1000000b --interactive --tty bash将内存或CPU限制设置为1,000,000字节。

要检查容器内的内存限制（以字节为单位），请使用以下命令：

cat /sys/fs/cgroup/memory/memory.limit_in_bytes

接下来我们一起来看下设置了--max_old_space_size之后容器的各种表现。

“旧生代”是V8内存托管堆的公共堆部分（即JavaScript对象所在的位置），并且该--max-old-space-size标志控制其最大大小。有关更多信息，请参阅关于-max-old-space-size。

通常，当应用程序使用的内存多于容器内存时，应用程序将终止。如果你想和更多容器技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

以下示例应用程序以10毫秒的间隔插入记录到列表。这个快速的间隔使得堆无限制地增长，模拟内存泄漏。

'use strict';

const list = [];

setInterval(()=> {

  const record = new MyRecord();

  list.push(record);

},10);

function MyRecord() {

  var x='hii';

  this.name = x.repeat(10000000);

  this.id = x.repeat(10000000);

  this.account = x.repeat(10000000);

}

setInterval(()=> {

  console.log(process.memoryUsage())

},100);

本文所有的示例程序都可以在我推入Docker Hub的Docker镜像中获得。你也可以拉取Docker镜像并运行程序。使用docker pull ravali1906/dockermemory来获取图像。

或者，你可以自己构建镜像，并使用内存限制运行镜像，如下所示：

docker run --memory 512m --interactive --tty ravali1906/dockermemory bash

ravali1906/dockermemory是镜像的名称。

接下来，运行内存大于容器限制的应用程序：

$ node --max_old_space_size=1024 test-fatal-error.js

{ rss: 550498304,

heapTotal: 1090719744,

heapUsed: 1030627104,

external: 8272 }

Killed

PS：

* --max_old_space_size 取M为单位的值
* process.memoryUsage() 以字节为单位输出内存使用情况

当内存使用率超过某个阈值时，应用程序终止。但这些阈值是多少？有什么限制？我们来看一下约束。
#在容器中设置了--max-old-space-size约束的预期结果
默认情况下，Node.js（适用于11.x版本及以下）在32位和64位平台上使用最大堆大小分别为700MB和1400MB。对于当前默认值，请参阅博客末尾参考文章。

因此，理论上，当设置--max-old-space-size内存限制大于容器内存时，期望应用程序应直接被OOM（Out Of Memory）终止。

实际上，这可能不会发生。
#在容器中设置了--max-old-space-size约束的实际结果
并非所有通过--max-old-space-size指定的内存的容量都可以提前分配给应用程序。

相反，为了响应不断增长的需求，JavaScript内存堆是逐渐增长的。

应用程序使用的实际内存（以JavaScript堆中的对象的形式）可以在process.memoryUsage()API中的heapUsed字段看到。

因此，现在修改后的期望是，如果实际堆大小（驻留对象大小）超过OOM-KILLER阈值（--memory容器中的标志），则容器终止应用程序。
实际上，这也可能不会发生。

当我在容器受限的环境下分析内存密集型Node.js应用程序时，我看到两种情况：

* OOM-KILLER在heapTotal和heapUsed的值都高于容器限制之后，隔一段很长的时间才执行。
* OOM-KILLER根本没有执行。

#容器环境中的Node.js相关行为解释
监控容器中运行应用程序的重要指标是驻留集大小（RSS-resident set size）。

它属于应用程序虚拟内存的一部分。

或者说，它代表应用程序被分配的内存的一部分。

更进一步说，它表示应用程序分配的内存中当前处于活动状态的部分。

并非应用程序中的所有已分配内存都属于活动状态，这是因为“分配的内存”只有在进程实际开始使用它时才会真实分配。另外，为了响应其他进程的内存需求，系统可能swap out当前进程中处于非活动或休眠状态的内存给其他进程，后续如果当前进程需要的时候通过swapped in重新分配回来。

RSS反映了应用程序的可用和活动的内存量。
#证明
##示例1.创建一个大小超过容器内存限制的空Buffer对象
以下buffer_example.js为往内存分配空Buffer对象的实例代码：

const buf = Buffer.alloc(+process.argv[2] [i] 1024 [/i] 1024)

console.log(Math.round(buf.length / (1024 * 1024)))

console.log(Math.round(process.memoryUsage().rss / (1024 * 1024)))

运行Docker镜像并限制其内存用量：

docker run --memory 1024m --interactive --tty ravali1906/dockermemory bash

运行该应用程序。你会看到以下内容：

$ node buffer_example 2000

2000

16

即使内存大于容器限制，应用程序也不会终止。这是因为分配的内存还未被完全访问。rss值非常低，并且没有超过容器内存限制。
##示例2.创建一个大小超过容器内存限制的并填满的Buffer对象
以下为往内存分配Buffer对象并填满值的实例代码：

const buf = Buffer.alloc(+process.argv[2] [i] 1024 [/i] 1024,'x')

console.log(Math.round(buf.length / (1024 * 1024)))

console.log(Math.round(process.memoryUsage().rss / (1024 * 1024)))

运行Docker镜像并限制其内存用量：

docker run --memory 1024m --interactive --tty ravali1906/dockermemory bash

运行该应用程序

$ node buffer_example_fill.js 2000

2000

984

即使在这里应用也没有被终止！为什么？当活动内存达到容器设置限制时，并且swap space还有空间时，一些旧内存片段将被推送到swap space并可供同一进程使用。默认情况下，docker分配的交换空间量等于通过--memory标志设置的内存限制。有了这种机制，这个进程几乎可以使用2GB内存 - 1GB活动内存和1GB交换空间。简而言之，由于内存的交换机制，rss仍然在容器强制限制范围内，并且应用程序能够持续运行。
##示例3.创建一个大小超过容器内存限制的空Buffer对象并且限制容器使用swap空间

const buf = Buffer.alloc(+process.argv[2] [i] 1024 [/i] 1024,'x')

console.log(Math.round(buf.length / (1024 * 1024)))

console.log(Math.round(process.memoryUsage().rss / (1024 * 1024)))

运行镜像时限制docker内存，交换空间和关闭匿名页面交换，如下所示：

docker run --memory 1024m --memory-swap=1024m --memory-swappiness=0 --interactive --tty ravali1906/dockermemory bash

$ node buffer_example_fill.js 2000

Killed

当--memory-swap的值等于--memory的值时，它表示容器不使用任何额外的交换空间。此外，默认情况下，容器的内核可以交换出一定比例的匿名页，因此将--memory-swappiness设置为0以禁用它。因此，由于容器内没有发生交换，rss超出了容器限制，在正确的时间终止了进程。
#总结和建议
当您运行Node.js应用程序并将其--max-old-space-size设置为大于容器限制时，看起来Node.js可能不会“尊重”容器强制限制。但正如您在上面的示例中看到的，原因是应用程序可能无法使用标志访问JavaScript堆集的全长。

请记住，当您使用的内存多于容器中可用的内存时，无法保证应用按期望行为方式运行。为什么？因为进程的活动内存（rss）受到许多因素的影响，这些因素超出了应用程序的控制范围，并且可能依赖于高负载和环境 - 例如工作负载本身，系统中的并发级别，操作系统调度程序，垃圾收集率等。此外，这些因素可以在运行之间发生变化。
#关于Node.js堆大小的建议（当你可以控制它，但不能控制容器大小时）

* 运行一个空的Node.js应用程序，并测量空转情况下rss的使用情况（我在Node.js v10.x版本得到它的值约为20 MB）。
* 由于Node.js在堆中具有其他内存区域（例如new_space，code_space等），因此假设其默认配置会占用额外的20 MB。如果更改其默认值，请相应地调整此值。
* 从容器中的可用内存中减去此值（40 MB），得到的值设置为JavaScript的旧生代大小，应该是一个相当安全的值。

#关于容器内存大小的建议（当你可以控制它，但不能控制Node.js内存时）

* 运行涵盖高峰工作负载的应用程序。
* 观察rss空间的增长。使用top命令和process.memoryUsage()API得到最高值。
* 如果容器中不存在其他活动进程，将此值用作容器的内存限制。该值上浮10%以上会更加安全。

#备注
如果在容器环境下运行，Node.js 12.x的堆内存限制根据当前可用内存进行配置，而不是使用默认值。对于设置了max_old_space_size的场景，上面的建议仍然适用。此外，了解相关限制可以让您更好地调整应用并发挥应用的性能，因为默认值是相对保守的。

有关更多信息，请参阅配置默认堆转储。

作者：Make_a_decision
链接：https://juejin.im/post/5cef9efc6fb9a07ec56e5cc5

概述

已经有了cadvisor、heapster、metric-server，几乎容器运行的所有指标都能拿到，但是下面这种情况却无能为力：

* 我调度了多少个replicas？现在可用的有几个？
* 多少个Pod是running/stopped/terminated状态？
* Pod重启了多少次？
* 我有多少job在运行中

而这些则是kube-state-metrics提供的内容，它基于client-go开发，轮询Kubernetes API，并将Kubernetes的结构化信息转换为metrics。

功能

kube-state-metrics提供的指标，按照阶段分为三种类别：

• 1.实验性质的：k8s api中alpha阶段的或者spec的字段。

• 2.稳定版本的：k8s中不向后兼容的主要版本的更新

• 3.被废弃的：已经不在维护的。

指标类别包括：* CronJob Metrics* DaemonSet Metrics* Deployment Metrics* Job Metrics* LimitRange Metrics* Node Metrics* PersistentVolume Metrics* PersistentVolumeClaim Metrics* Pod Metrics* Pod Disruption Budget Metrics* ReplicaSet Metrics* ReplicationController Metrics* ResourceQuota Metrics* Service Metrics* StatefulSet Metrics* Namespace Metrics* Horizontal Pod Autoscaler Metrics* Endpoint Metrics* Secret Metrics* ConfigMap Metrics以pod为例：* kube_pod_info* kube_pod_owner* kube_pod_status_phase* kube_pod_status_ready* kube_pod_status_scheduled* kube_pod_container_status_waiting* kube_pod_container_status_terminated_reason* ... 使用部署清单：

 kube-state-metrics/    ├── kube-state-metrics-cluster-role-binding.yaml    ├── kube-state-metrics-cluster-role.yaml    ├── kube-state-metrics-deployment.yaml    ├── kube-state-metrics-role-binding.yaml    ├── kube-state-metrics-role.yaml    ├── kube-state-metrics-service-account.yaml    ├── kube-state-metrics-service.yaml

主要镜像有：image: quay.io/coreos/kube-state-metrics:v1.5.0image: k8s.gcr.io/addon-resizer:1.8.3（参考metric-server文章，用于扩缩容）对于pod的资源限制，一般情况下：`200MiB memory0.1 cores`超过100节点的集群：`2MiB memory per node0.001 cores per node`kube-state-metrics做过一次性能优化，具体内容参考下文部署成功后，prometheus的target会出现如下标志 因为kube-state-metrics-service.yaml中有`prometheus.io/scrape: 'true'`标识，因此会将metric暴露给prometheus，而Prometheus会在kubernetes-service-endpoints这个job下自动发现kube-state-metrics，并开始拉取metrics，无需其他配置。如果你想和更多监控技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。使用kube-state-metrics后的常用场景有：存在执行失败的Job: kube_job_status_failed{job="kubernetes-service-endpoints",k8s_app="kube-state-metrics"}==1

• 集群节点状态错误: kube_node_status_condition{condition="Ready",status!="true"}==1
• 集群中存在启动失败的Pod：kube_pod_status_phase{phase=~"Failed|Unknown"}==1
• 最近30分钟内有Pod容器重启: changes(kube_pod_container_status_restarts[30m])>0

配合报警可以更好地监控集群的运行 与metric-server的对比* metric-server（或heapster）是从api-server中获取cpu、内存使用率这种监控指标，并把他们发送给存储后端，如influxdb或云厂商，他当前的核心作用是：为HPA等组件提供决策指标支持。

• kube-state-metrics关注于获取k8s各种资源的最新状态，如deployment或者daemonset，之所以没有把kube-state-metrics纳入到metric-server的能力中，是因为他们的关注点本质上是不一样的。metric-server仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而kube-state-metrics是将k8s的运行状况在内存中做了个快照，并且获取新的指标，但他没有能力导出这些指标

• 换个角度讲，kube-state-metrics本身是metric-server的一种数据来源，虽然现在没有这么做。

• 另外，像Prometheus这种监控系统，并不会去用metric-server中的数据，他都是自己做指标收集、集成的（Prometheus包含了metric-server的能力），但Prometheus可以监控metric-server本身组件的监控状态并适时报警，这里的监控就可以通过kube-state-metrics来实现，如metric-serverpod的运行状态。

深入解析kube-state-metrics本质上是不断轮询api-server，代码结构也很简单主要代码目录

.├── collectors│   ├── builder.go│   ├── collectors.go│   ├── configmap.go│   ......│   ├── testutils.go│   ├── testutils_test.go│   └── utils.go├── constant│   └── resource_unit.go├── metrics│   ├── metrics.go│   └── metrics_test.go├── metrics_store│   ├── metrics_store.go│   └── metrics_store_test.go├── options│   ├── collector.go│   ├── options.go│   ├── options_test.go│   ├── types.go│   └── types_test.go├── version│   └── version.go└── whiteblacklist    ├── whiteblacklist.go    └── whiteblacklist_test.go

所有类型：

var (	DefaultNamespaces = NamespaceList{metav1.NamespaceAll}	DefaultCollectors = CollectorSet{		"daemonsets":               struct{}{},		"deployments":              struct{}{},		"limitranges":              struct{}{},		"nodes":                    struct{}{},		"pods":                     struct{}{},		"poddisruptionbudgets":     struct{}{},		"replicasets":              struct{}{},		"replicationcontrollers":   struct{}{},		"resourcequotas":           struct{}{},		"services":                 struct{}{},		"jobs":                     struct{}{},		"cronjobs":                 struct{}{},		"statefulsets":             struct{}{},		"persistentvolumes":        struct{}{},		"persistentvolumeclaims":   struct{}{},		"namespaces":               struct{}{},		"horizontalpodautoscalers": struct{}{},		"endpoints":                struct{}{},		"secrets":                  struct{}{},		"configmaps":               struct{}{},	})

构建对应的收集器Family即一个类型的资源集合，如job下的kube_job_info、kube_job_created，都是一个FamilyGenerator实例

metrics.FamilyGenerator{			Name: "kube_job_info",			Type: metrics.MetricTypeGauge,			Help: "Information about job.",			GenerateFunc: wrapJobFunc(func(j *v1batch.Job) metrics.Family {				return metrics.Family{&metrics.Metric{					Name:  "kube_job_info",					Value: 1,				}}			}),		},

func (b [i]Builder) buildCronJobCollector() [/i]Collector {   // 过滤传入的白名单	filteredMetricFamilies := filterMetricFamilies(b.whiteBlackList, cronJobMetricFamilies)	composedMetricGenFuncs := composeMetricGenFuncs(filteredMetricFamilies)  // 将参数写到header中	familyHeaders := extractMetricFamilyHeaders(filteredMetricFamilies)  // NewMetricsStore实现了client-go的cache.Store接口，实现本地缓存。	store := metricsstore.NewMetricsStore(		familyHeaders,		composedMetricGenFuncs,	)  // 按namespace构建Reflector，监听变化	reflectorPerNamespace(b.ctx, b.kubeClient, &batchv1beta1.CronJob{}, store, b.namespaces, createCronJobListWatch)	return NewCollector(store)}

性能优化：kube-state-metrics在之前的版本中暴露出两个问题：

• 1. /metrics接口响应慢(10-20s)
• 2. 内存消耗太大，导致超出limit被杀掉

问题一的方案就是基于client-go的cache tool实现本地缓存，具体结构为：`var cache = map[uuid][]byte{}`问题二的的方案是：对于时间序列的字符串，是存在很多重复字符的（如namespace等前缀筛选），可以用指针或者结构化这些重复字符。 优化点和问题

• 1.因为kube-state-metrics是监听资源的add、delete、update事件，那么在kube-state-metrics部署之前已经运行的资源，岂不是拿不到数据？kube-state-metric利用client-go可以初始化所有已经存在的资源对象，确保没有任何遗漏

• 2.kube-state-metrics当前不会输出metadata信息(如help和description）

• 3.缓存实现是基于golang的map，解决并发读问题当期是用了一个简单的互斥锁，应该可以解决问题，后续会考虑golang的sync.Map安全map。

• 4.kube-state-metrics通过比较resource version来保证event的顺序

• 5.kube-state-metrics并不保证包含所有资源

监控数据展示

基于kube-state-metrics的监控数据，可以组装一些常用的监控面板，如下面的grafana面板：


本文为容器监控实践系列文章，完整内容见：container-monitor-book

#前言
在我入职上家公司的运维部之前，我所以为的运维工程师只是修修电脑，拉拉网线，布布机器。

诸不知，运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多：

* 桌面运维工程师
* 业务运维工程师
* DBA工程师
* 配置工程师
* 运维开发工程师
* 以及其它....


原本准备写篇前端眼中的运维开发，恰巧前组长写了两篇结合自身六七年开发经验写的体会。用他的文章来阐述再合适不过了。以下来自其投稿以及穿插一些知识普及。
#DevOps：打破协作壁垒
来自维基百科：

DevOps（Development和Operations的组合詞）是一种重视「软件开发人员（Dev）」和「IT运维技术人员（Ops）」之间沟通合作的文化、运动或慣例。如果你想和更多DevOps技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

透过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。

按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；

而现在却需要极其紧密的多部门协作。而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

具体来说，就是在 软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。
#运维开发的价值
从岗位职责来看，运维开发要做的工作是：

通过开发技能帮助运维实现运维工作的自动化。说白了就是“辅助”，或者说是运维的臂膀，需要把运维中遇到的问题提供平台查询，或者把一些常见的重复操作给抽象出来做成工具，减少运维的人工介入。

运维服务伴随并支撑着业务发展的整个生命周期。

而DevOps将运维服务的执行方式升级为更加软件工程化的手段，减少人肉操作，DevOps 强调自动化、拉动式来提高团队交付效率与质量。

而传统的运维需要谋求技术转型，从原来只关注操作系统层面的技术已经不够了，还要增加对程序代码的性能调优、持续交付、容器化等软件基础架构方面的技能提升，也需要持续关注整个业务、应用、服务的生命周期管理。

简单来说，就是把过去传统的黑盒运维的思维方式抛弃，进入白盒运维的时代，我们必须更加深入代码、深入业务运营，让整个线上服务运行于更优质高效的状态。
#运维开发是什么？
要建设运维自动化或者实践 DevOps 离不开运维开发工程师的参与，但要怎样才能更好地发挥运维开发的作用呢？

我曾作为运维开发经理的角色和各种类型的运维开发一起协作过，团队中有本来就做运维开发的，也有本来做其他业务（电商、平台）的开发转来协助运维团队的，还有原本是做业务运维后来转型做运维开发的。
和他们协作一段日子后，总体感觉如下：

运维开发首先是一个程序员，不是运维工程师。

一个好的运维开发需要具备 「运维理解」+「开发能力」：

* 对「开发能力」的技术要求低于其他业务形态（如游戏、电商、搜索等）。
* 对运维业务的理解难度会低于电商、游戏等业务形态，即对「运维理解」的要求不高。
* 对运维相关技术栈的掌握程度要求高，如Python/PHP/Go/Shell、 Linux、Git、Nginx、Zabbix、Docker、Kubernetes等。


综上所述，运维开发是一个深度不算太深的职业分支，而现在之所以对运维开发需求量热起来了，主要由于老一辈的资深运维普遍研发能力有限，而这是有历史原因的。等到业界提出 DevOps的时候，他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等高级范畴，所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

所以，当我们有自动化系统的建设需求时，需要更专业的程序员来协助。但一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使，这时候有部分年轻的运维工程师升级了研发技能，转型运维开发，把好使的运维系统做出来了，赢得了运维团队的好评，大家都为「运维开发」点赞。

所以，大家将 「好使的运维系统」 和 「运维开发」 等价起来，以为我们只要招来一个运维开发，那么一套完美的运维平台就能自动诞生出来，这是个很大的误区。
#打造「好使的DevOps系统」
其实「好使的DevOps系统」真正等价于「运维理解」+「开发能力」，这两种能力也是可以分离的，不一定要强加在运维开发工程师一个人的身上。

类似其他业务形态的开发过程，需要产品经理和程序员两种角色分离，企业也不会说要招聘既会写代码、又会出需求的程序员。

所以，当运维能把运维自动化的需求细致地文档化下来，把自动化系统的设计、架构等关键环节确立下来，这就是最好的「运维理解」。这时把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员，最终就可以得到「好使的运维系统」。

当然， 一般企业不会专门为运维开发配备「产品经理」，所以运维开发想要再往高级发展的话，也可以替代运维出需求，升级为运维产品经理，以程序员的思维角度来解决运维服务的工程效率和质量问题，我认为这也是类似 Google 所提倡的 SRE 文化。
##DevOps平台
编者补充描述。

光说不练假把戏，编者在上家公司的主职就是将DevOps操作界面化。
其中的核心模块：应用部署发布监控。

图为DevOps应用部署发布监控界面图：

我们组在做上图的DevOps系统时，面临的情况是：无产品、无设计、需求也是靠业务运维和开发们的口头描述。

其中的核心功能：应用部署界面，在参考其它同类产品后，发现都不适合业务场景，要么功能太分散，要么就仅是流程控制。于是前端功能里，我们做了这些：

* 区分不同环境下的包，实现有序管理。
* 应用的状态可以通过界面做启停、查看配置等任务。
* Jenkins服务操作可通过界面完成，简化配置工程师的工作。
* 业务运维与开发团队的日常发包工作界面化。

此时一个优秀的运维开发需具备以下技能：产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等。

所以，当运维需求被理解、分析得足够透彻，以及运维开发获得了「产品经理」能力后，运维开发就是一种普通的开发分支，按需求文档编码即可。
#优秀的运维开发
从事DevOps平台开发相关工作已有六七年了，自身经历总结，觉得一个优秀的运维开发工程师应当具备以下能力和素质。
##提高运维意识。
从下到上，从上到下的工作都要做好，对上运维工作的价值和含金量可以得到认可，对下我们的工作能够提高效率解放运维。

运维意识是很重要，并不是你技术很牛，学的技术很多很熟，就不代表你不需要运维意识。

其实领导很看重运维意识的，例如有没有做好备份，权限分配问题，平台测试情况，故障响应时间等，这些都是意识，而不是你学了很多技术自认大牛了，平台发现故障你又没什么大不子，以为很简单的问题喜欢处理就处理，不需要向其它部门反馈等，领导不是看你的技术如何，而是看你的运维意识如何，你没运维意识，技术再牛也没用，只会让其它部门的人跟你不协调。
##了解业务场景
DevOps平台最终服务于运维部和开发测试部同事，因此只有熟悉了解了每一项业务的运维场景，才能更好去设计功能与代码开发，熟悉业务场景才能方方面面考虑周全，开发出来的代码才能满足各类场景应用。
##拒绝重复犯错
人难免会犯错，这是无法避免的，我们应当根据已有的犯错经验，总结犯错的原因，以及如何避免同类情况再次发生，甚至可以把一些典型的错误在团队中分享，把一个人的错误得到的经验传播于整个团队。
##凡事有备份，可回退
运维工作中经常有一些发布，迁移，备份等复杂操作，因此，在研发DevOPs平台的时候，要做好全面的操作计划，思考每一步可能的回退与备份。
##平台操作尽量简化
DevOps平台目的就是为了能够提高运维的工作效率，解放运维，因此在设计与开发的时候，应当保持操作简单，不要让事情变得太复杂，能点一下到位的，尽量不要让人点五六下才能完成操作。
##注重优化用户体验
DevOps开发是一个迭代的过程，虽然我们常说以功能开发为主，但是用户体验也同等重要，试想一下，纵使你开发的功能众多，如果体验不友好，用户便失去了再次使用的欲望，如果用户拒绝，抵触使用平台，做再多功能也是失败，最终平台推广失败。因此，在研发的过程中，我们应当深入体验自己开发的产品，把自己当成用户去体验平台操作。尽可能的去优化用户体验。这是一个优秀的运维开发工程师必需要懂的。

在设计与开发的过程中经常会碰到复杂，繁琐的场景，这个时候我们很容易失去耐心，我们要时刻提醒自己，必须严格履行自己的工作职责，端正自己的工作态度，做一件事，要么不做，既然做了就要做好：当你想要放弃的时候,想想当初为什么要开始。
#总结
本文是我个人对运维开发以及其职业发展的一些浅薄理解，总的来说，运维开发还是一个比较有意思且有良好发展的职业分支，虽然偶尔也要背黑锅，但也欢迎更多努力、聪明、有才华的同学加入运维开发行业。

链接：https://juejin.im/post/5cf29a6ae51d45778f076cd2