通知设置 新通知
服务端高并发分布式架构演进之路
翔宇 发表了文章 • 0 个评论 • 250 次浏览 • 2019-06-04 11:16
【编者的话】本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
#基本概念
在介绍架构之前，为 ...查看全部
【编者的话】本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。
#基本概念
在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：
##分布式
系统中的多个模块在不同服务器上部署，即可称为分布式系统，如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
#基本概念
在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：
##分布式
系统中的多个模块在不同服务器上部署，即可称为分布式系统，如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
微服务化后缓存怎么做
大卫 发表了文章 • 0 个评论 • 212 次浏览 • 2019-06-03 15:41
【编者的话】最近接手的代码中遇到几个缓存的问题，存在一些设计原则的问题，这里总结一下，希望可以对你有帮助。
#问题
问题1： 店铺数据的获取，将用户关注的数据放在店铺信息一起返回。
对外提供的接口： ...查看全部
【编者的话】最近接手的代码中遇到几个缓存的问题，存在一些设计原则的问题，这里总结一下，希望可以对你有帮助。
#问题
问题1： 店铺数据的获取，将用户关注的数据放在店铺信息一起返回。
对外提供的接口：
返回的店铺信息：
当调用方设置cache为true时，因为有缓存的存在，获取不到用户是否关注的数据。
问题2： 统计店铺的被关注数导致的慢SQL,导致数据库cpu飙高，影响到了整个应用。
SQL：
这两种代码的写法都是基于一个基准。
不同的地方的缓存策略不一样，比如我更新的地方，查找数据时不能缓存，页面展示的查找的地方需要缓存。 既然服务提供方不知道该不该缓存，那就不管了，交给调用方去管理。如果你想和更多微服务技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
这种假设本身没什么问题，但是忽略了另外一个原则，服务的内聚性。不应该被外部知道的就没必要暴露给外部。
无论是面向过程的C，还是面向对象的语言，都强调内聚性，也就是高内聚，低耦合。单体应用中应当遵循这个原则，微服务同样遵循这个原则。但是在实际过程中，我们发现做到高内聚并不简单。我们必须要时时刻刻审视方法/服务的边界，只有确定好职责边界，才能写出高内聚的代码。
#问题分析
第一个问题，从缓存的角度来看，是忽略了数据的更新频繁性以及数据获取的不同场景。
对于店铺这样一个大的聚合根，本身包含的信息很多，有些数据可能会被频繁更改的，有些则会很少更新的。那么不同的修改频率，是否缓存/缓存策略自然不同，使用同一个参数Boolean cache来控制显然不妥
第二个问题，这种统计类的需求使用SQL统计是一种在数据量比较小的情况下的权宜之计，当数据规模增大后，必须要使用离线计算或者流式计算来解决。它本身是一个慢SQL，所以必须要控制号调用量，这种统计的数据量的时效性应该由服务方控制，不需要暴露给调用方。否则就会出现上述的问题，调用方并不清楚其中的逻辑，不走缓存的话就会使得调用次数增加，QPS的增加会导致慢SQL打垮数据库。
#解法
缓存更新本身就是一个难解的问题，在微服务化后，多个服务就更加复杂了。涉及到跨服务的多级缓存一致性的问题。
所以对大部分的业务，我们可以遵循这样的原则来简单有效处理。
对数据的有效性比较敏感的调用都收敛到服务内部（领域内部应该更合适），不要暴露给调用方。
领域内部做数据的缓存失效控制。
缓存预计算（有些页面的地方不希望首次打开慢）的逻辑也应该放在领域内控制，不要暴露给调用方。
在领域内部控制在不同的地方使用不同的缓存策略，比如更新数据的地方需要获取及时的数据。比如商品的价格，和商品的所属类目更新频次不同，需要有不同的过期时间。
跨服务调用为了减少rpc调用，可以再进行一层缓存。因为这些调用可以接受过期的数据，再进行一层缓存没问题，expired time叠加也没多大影响（expire time在这边主要是影响缓存的命中数）
以上述店铺查询问题改造为例
扩展：如果后续有case在跨服务的调用时，对数据的过期比较敏感，并且在调用方也做了缓存，那就是跨服务的多级缓存一致性的问题。那就需要服务方告知调用方缓存何时失效，使用消息队列or其他方式来实现。
作者：方丈的寺院
原文：https://fangzhang.blog.csdn.net/article/details/89892575
#问题
问题1： 店铺数据的获取，将用户关注的数据放在店铺信息一起返回。
对外提供的接口：
ListgetPageShop(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
闲聊我心中的运维开发
aoxiang 发表了文章 • 0 个评论 • 233 次浏览 • 2019-06-03 12:21
#前言
在我入职上家公司的运维部之前，我所以为的运维工程师只是修修电脑，拉拉网线，布布机器。
诸不知，运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多 ...查看全部
#前言
在我入职上家公司的运维部之前，我所以为的运维工程师只是修修电脑，拉拉网线，布布机器。
诸不知，运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多：
* 桌面运维工程师
* 业务运维工程师
* 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
在我入职上家公司的运维部之前，我所以为的运维工程师只是修修电脑，拉拉网线，布布机器。
诸不知，运维所涉及的知识面、专业点非常广，对从业人员素质也要求非常高，运维工作在大型互联网公司的重要性不比业务开发差。且分类繁多：
* 桌面运维工程师
* 业务运维工程师
* 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
GitLab CI/CD 在 Node.js 项目中的实践
尼古拉斯 发表了文章 • 0 个评论 • 179 次浏览 • 2019-06-03 09:58
【编者的话】近期在按照业务划分项目时，我们组被分了好多的项目过来，大量的是基于 Node.js 的，也是我们组持续在使用的语言。
#现有流程中的一些问题
在维护多个项目的时候，会暴露出一些问题：
如何有效的使用 ...查看全部
【编者的话】近期在按照业务划分项目时，我们组被分了好多的项目过来，大量的是基于 Node.js 的，也是我们组持续在使用的语言。
#现有流程中的一些问题
在维护多个项目的时候，会暴露出一些问题：
* 使用了 TypeScript 以后带来的额外成本
##测试用例
首先是测试用例，最初我们设计在了 git hooks 里边，在执行 git commit 之前会进行检查，在本地运行测试用例。 如果你想和更多 GitLab 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
这会带来一个时间上的问题，如果是日常开发，这么操作还是没什么问题的，但如果是线上 bug 修复，执行测试用例的时间依据项目大小可能会持续几分钟。
而为了修复 bug，可能会采用 commit 的时候添加 -n 选项来跳过 hooks，在修复 bug 时这么做无可厚非，但是即使大家在日常开发中都采用commit -n 的方式来跳过繁琐的测试过程，这个也是没有办法管控的，毕竟是在本地做的这个校验，是否遵循这个规则，全靠大家自觉。
所以一段时间后发现，通过这种方式执行测试用例来规避一些风险的作用可能并不是很有效。
##ESLint
然后就是 ESLint，我们团队基于airbnb的 ESLint 规则自定义了一套更符合团队习惯的规则，我们会在编辑器中引入插件用来帮助高亮一些错误，以及进行一些自动格式化的操作。
同时我们也在 git hooks 中添加了对应的处理，也是在 git commit 的时候进行检查，如果不符合规范则不允许提交。
不过这个与测试用例是相同的问题：
##部署上线的方式
之前团队的部署上线是使用shipit周边套件进行部署的。
部署环境强依赖本地，因为需要在本地建立仓库的临时目录，并经过多次ssh XXX "command"的方式完成部署 + 上线的操作。
shipit提供了一个有效的回滚方案，就是在部署后的路径添加多个历史部署版本的记录，回滚时将当前运行的项目目录指向之前的某个版本即可。（不过有一点儿坑的是，很难去选择我要回滚到那个节点，以及保存历史记录需要占用额外的磁盘空间）
不过正因为如此，shipit在部署多台服务器时会遇到一些令人不太舒服的地方。
如果是多台新增的服务器，那么可以通过在shipit配置文件中传入多个目标服务器地址来进行批量部署。
但是假设某天需要上线一些小流量（比如四台机器中的一台），因为前边提到的shipit回滚策略，这会导致单台机器与其他三台机器的历史版本时间戳不一致（因为这几台机器不是同一时间上线的）
也就是说，哪怕有一次进行过小流量上线，那么以后就用不了批量上线的功能了 （没有去仔细研究shipit官方文档，不知道会不会有类似--force之类的忽略历史版本的操作）
基于上述的情况，我们的部署上线耗时变为了： （__机器数量__）X（__基于本地网速的仓库克隆、多次 ssh 操作的耗时总和__）。 P.S. 为了保证仓库的有效性，每次执行 shipit 部署，它都会删除之前的副本，重新克隆
尤其是服务端项目，有时紧急的 bug 修复可能是在非工作时间，这意味着可能当时你所处的网络环境并不是很稳定。
我曾经晚上接到过同事的微信，让我帮他上线项目，他家的 Wi-Fi 是某博士的，下载项目依赖的时候出了些问题。
还有过使用移动设备开热点的方式进行上线操作，有一次非前后分离的项目上线后，直接就收到了联通的短信：「您本月流量已超出XXX」（当时还在用合约套餐，一月就800M流量）。
##TypeScript
在去年下半年开始，我们团队就一直在推动 TypeScript 的应用，因为在大型项目中，拥有明确类型的 TypeScript 显然维护性会更高一些。
但是大家都知道的， TypeScript 最终需要编译转换为 JavaScript（也有 tsc 那种的不生成 JS 文件，直接运行，不过这个更多的是在本地开发时使用，线上代码的运行我们还是希望变量越少越好）。
所以之前的上线流程还需要额外的增加一步，编译 TS。
而且因为shipit是在本地克隆的仓库并完成部署的，所以这就意味着我们必须要把生成后的 JS 文件也放入到仓库中，最直观的，从仓库的概览上看着就很丑（50% TS、50% JS），同时这进一步增加了上线的成本。
总结来说，现有的部署上线流程过于依赖本地环境，因为每个人的环境不同，这相当于给部署流程增加了很多不可控因素。
#如何解决这些问题
上边我们所遇到的一些问题，其实可以分为两块：
所以我们就开始寻找解决方案，因为我们的源码是使用自建的 GitLab 仓库来进行管理的，首先就找到了 GitLab CI/CD。
在研究了一番文档以后发现，它能够很好的解决我们现在遇到的这些问题。
要使用 GitLab CI/CD 是非常简单的，只需要额外的使用一台服务器安装 gitlab-runner，并将要使用 CI/CD 的项目注册到该服务上就可以了。
GitLab 官方文档中有非常详细的安装注册流程：
install | runner
register | runner
group register | repo 注册 Group 项目时的一些操作
上边的注册选择的是注册 group ，也就是整个 GitLab 某个分组下所有的项目。
主要目的是因为我们这边项目数量太多，单个注册太过繁琐（还要登录到 runner 服务器去执行命令才能够注册）
##安装时需要注意的地方
官网的流程已经很详细了，不过还是有一些地方可以做一些小提示，避免踩坑。
这是 Linux 版本的安装命令，安装需要 root （管理员） 权限，后边跟的两个参数：
* --user 是 CI/CD 执行 job （后续所有的流程都是基于 job 的）时所使用的用户名
* --working-directory 是 CI/CD 执行时的根目录路径 个人的踩坑经验是将目录设置为一个空间大的磁盘上，因为 CI/CD 会生成大量的文件，尤其是如果使用 CI/CD 进行编译 TS 文件并且将其生成后的 JS 文件缓存；这样的操作会导致 innode 不足产生一些问题
##注册时需要注意的地方
在按照官网的流程执行时，我们的 tag 是留空的，暂时没有找到什么用途。
以及 executor 这个比较重要了，因为我们是从手动部署上线还是往这边靠拢的，所以稳妥的方式是一步步来，也就是说我们选择的是 shell ，最常规的一种执行方式，对项目的影响也是比较小的（官网示例给的是 Docker）。
##.gitlab-ci.yml 配置文件
上边的环境已经全部装好了，接下来就是需要让 CI/CD 真正的跑起来
runner 以哪种方式运行，就靠这个配置文件来描述了，按照约定需要将文件放置到 repo 仓库的根路径下。
当该文件存在于仓库中，执行 git push 命令后就会自动按照配置文件中所描述的动作进行执行了。
* quick start
* configuration
上边的两个链接里边信息非常完整，包含各种可以配置的选项。
一般来讲，配置文件的结构是这样的：
stages 用来声明有效的可被执行的 stage，按照声明的顺序执行。
下边的那些 job XXX 名字不重要，这个名字是在 GitLab CI/CD Pipeline 界面上展示时使用的，重要的是那个 stage 属性，他用来指定当前的这一块 job 隶属于哪个 stage。
script 则是具体执行的脚本内容，如果要执行多行命令，就像job 3那种写法就好了。
如果我们将上述的 stage、job 之类的换成我们项目中的一些操作install_dependencies、test、eslint之类的，然后将script字段中的值换成类似npx eslint之类的，当你把这个文件推送到远端服务器后，你的项目就已经开始自动运行这些脚本了。
并且可以在Pipelines界面看到每一步执行的状态。
P.S. 默认情况下，上一个 stage 没有执行完时不会执行下一个 stage 的，不过也可以通过额外的配置来修改：
* allow failure
* when
设置仅在特定的情况下触发 CI/CD
上边的配置文件存在一个问题，因为在配置文件中并没有指定哪些分支的提交会触发 CI/CD 流程，所以默认的所有分支上的提交都会触发，这必然不是我们想要的结果。
CI/CD 的执行会占用系统的资源，如果因为一些开发分支的执行影响到了主干分支的执行，这是一件得不偿失的事情。
所以我们需要限定哪些分支才会触发这些流程，也就是要用到了配置中的 only 属性。
使用only可以用来设置哪些情况才会触发 CI/CD，一般我们这边常用的就是用来指定分支，这个是要写在具体的 job 上的，也就是大致是这样的操作：
具体的配置文档
单个的配置是可以这样写的，不过如果 job 的数量变多，这么写就意味着我们需要在配置文件中大量的重复这几行代码，也不是一个很好看的事情。
所以这里可能会用到一个yaml的语法：
一个类似模版继承的操作，官方文档中也没有提到，这个只是一个减少冗余代码的方式，可有可无。
##缓存必要的文件
因为默认情况下，CI/CD在执行每一步（job）时都会清理一下当前的工作目录，保证工作目录是干净的、不包含一些之前任务留下的数据、文件。
不过这在我们的 Node.js 项目中就会带来一个问题。
因为我们的 ESLint、单元测试 都是基于 node_modules 下边的各种依赖来执行的。
而目前的情况就相当于我们每一步都需要执行npm install，这显然是一个不必要的浪费。
所以就提到了另一个配置文件中的选项：cache
用来指定某些文件、文件夹是需要被缓存的，而不能清除：
大致是这样的一个操作，CI_BUILD_REF_NAME是一个 CI/CD 提供的环境变量，该变量的内容为执行 CI/CD 时所使用的分支名，通过这种方式让两个分支之间的缓存互不影响。
##部署项目
如果基于上边的一些配置，我们将 单元测试、ESLint 对应的脚本放进去，他就已经能够完成我们想要的结果了，如果某一步执行出错，那么任务就会停在那里不会继续向后执行。
不过目前来看，后边已经没有多余的任务供我们执行了，所以是时候将 部署 这一步操作接过来了。
部署的话，我们目前选择的是通过 rsync 来进行同步多台服务器上的数据，一个比较简单高效的部署方式。
P.S. 部署需要额外的做一件事情，就是建立从gitlab runner所在机器gitlab-runner用户到目标部署服务器对应用户下的机器信任关系。
有 N 多种方法可以实现，最简单的就是在runner机器上执行 ssh-copy-id 将公钥写入到目标机器。
或者可以像我一样，提前将 runner 机器的公钥拿出来，需要与机器建立信任关系时就将这个字符串写入到目标机器的配置文件中。
类似这样的操作：ssh 10.0.0.1 "echo \"XXX\" >> ~/.ssh/authorized_keys"
大致的配置如下：
同时用到的还有variables，用来提出一些变量，在下边使用。
`ssh 10.0.0.1 "pm2 start $DEPLOY_TO/pm2/$CI_ENVIRONMENT_NAME.json;"`，这行脚本的用途就是重启服务了，我们使用pm2来管理进程，默认的约定项目路径下的pm2文件夹存放着个个环境启动时所需的参数。
当然了，目前我们在用的没有这么简单，下边会统一提到。
并且在部署的这一步，我们会有一些额外的处理。
这是比较重要的一点，因为我们可能会更想要对上线的时机有主动权，所以 deploy 的任务并不是自动执行的，我们会将其修改为手动操作还会触发，这用到了另一个配置参数：
当然了，如果不需要，这个移除就好了，比如说我们在测试环境就没有配置这个选项，仅在线上环境使用了这样的操作。
##更方便的管理 CI/CD 流程
如果按照上述的配置文件进行编写，实际上已经有了一个可用的、包含完整流程的 CI/CD 操作了。
不过它的维护性并不是很高，尤其是如果 CI/CD 被应用在多个项目中，想做出某项改动则意味着所有的项目都需要重新修改配置文件并上传到仓库中才能生效。
所以我们选择了一个更灵活的方式，最终我们的 CI/CD 配置文件是大致这样子的（省略了部分不相干的配置）：
我们将每一步 CI/CD 所需要执行的脚本都放到了 runner 那台服务器上，在配置文件中只是执行了那个脚本文件。
这样当我们有什么策略上的调整，比如说 ESLint 规则的变更、部署方式之类的。
这些都完全与项目之间进行解耦，后续的操作基本都不会让正在使用 CI/CD 的项目重新修改才能够支持（部分需要新增环境变量的导入之类的确实需要项目的支持）。
##接入钉钉通知
实际上，当 CI/CD 执行成功或者失败，我们可以在 Pipeline 页面中看到，也可以设置一些邮件通知，但这些都不是时效性很强的。
鉴于我们目前在使用钉钉进行工作沟通，所以就研究了一波钉钉机器人。
发现有支持 GitLab 机器人，不过功能并不适用，只能处理一些 issues 之类的， CI/CD 的一些通知是缺失的，所以只好自己基于钉钉的消息模版实现一下了。
因为上边我们已经将各个步骤的操作封装了起来，所以这个修改对同事们是无感知的，我们只需要修改对应的脚本文件，添加钉钉的相关操作即可完成，封装了一个简单的函数：
上述用到的环境变量，除了DINGTALK_HOOKS_URL是我们自定义的机器人通知地址以外，其他的变量都是有 GitLab runenr所提供的。
各种变量可以从这里找到：predefined variables
##回滚处理
聊完了正常的流程，那么也该提一下出问题时候的操作了。
人非圣贤孰能无过，很有可能某次上线一些没有考虑到的地方就会导致服务出现异常，这时候首要任务就是让用户还可以照常访问，所以我们会选择回滚到上一个有效的版本去。
在项目中的 Pipeline 页面 或者 Enviroment 页面（这个需要在配置文件中某些 job 中手动添加这个属性，一般会写在 deploy 的那一步去），可以在页面上选择想要回滚的节点，然后重新执行 CI/CD 任务，即可完成回滚。
不过这在 TypeScript 项目中会有一些问题，因为我们回滚一般来讲是重新执行上一个版本 CI/CD 中的 deploy 任务，在 TS 项目中，我们在 runner 中缓存了 TS 转换 JS 之后的 dist 文件夹，并且部署的时候也是直接将该文件夹推送到服务器的（TS项目的源码就没有再往服务器上推过了）。
而如果我们直接点击 retry 就会带来一个问题，因为我们的 dist 文件夹是缓存的，而 deploy 并不会管这种事儿，他只会把对应的要推送的文件发送到服务器上，并重启服务。
而实际上 dist 还是最后一次（也就是出错的那次）编译出来的 JS 文件，所以解决这个问题有两种方法：
第一个方案肯定是不可行的，因为严重依赖于操作上线的人是否知道有这个流程。
所以我们主要是通过第二种方案来解决这个问题。
我们需要让脚本在执行的时候知道，dist 文件夹里边的内容是不是自己想要的。
所以就需要有一个 __标识__，而做这个标识最简单有效唾手可得的就是，git commit id。
每一个 commit 都会有一个唯一的标识符号，而且我们的 CI/CD 执行也是依靠于新代码的提交（也就意味着一定有 commit）。
所以我们在 build 环节将当前的commit id也缓存了下来：
同时在 deploy 脚本中添加额外的判断逻辑：
这样一来，就避免了回滚时还是部署了错误代码的风险。
关于为什么不将 build 这一步操作与 deploy 合并的原因是这样的：
因为我们会有很多台机器，同时 job 会写很多个，类似 deploy_1、deploy_2、deploy_all，如果我们将 build 的这一步放到 deploy 中。
那就意味着我们每次 deploy，即使是一次部署，但因为我们选择一台台机器单独操作，它也会重新生成多次，这也会带来额外的时间成本。
##hot fix 的处理
在 CI/CD 运行了一段时间后，我们发现偶尔解决线上 bug 还是会比较慢，因为我们提交代码后要等待完整的 CI/CD 流程走完。
所以在研究后我们决定，针对某些特定情况hot fix，我们需要跳过ESLint、单元测试这些流程，快速的修复代码并完成上线。
CI/CD 提供了针对某些 Tag 可以进行不同的操作，不过我并不想这么搞了，原因有两点：
所以我们采用了另一种取巧的方式来实现，因为我们的分支都是只接收Merge Request那种方式上线的，所以他们的commit title实际上是固定的：Merge branch 'XXX'。
同时 CI/CD 会有环境变量告诉我们当前执行 CI/CD 的 commit message。
我们通过匹配这个字符串来检查是否符合某种规则来决定是否跳过这些job：
这样能够保证如果我们的分支名为 hotfix/XXX 或者 fix/XXX 在进行代码合并时， CI/CD 会跳过多余的代码检查，直接进行部署上线。 没有跳过安装依赖的那一步，因为 TS 编译还是需要这些工具的。
#小结
目前团队已经有超过一半的项目接入了 CI/CD 流程，为了方便同事接入（主要是编辑 .gitlab-ci.yml 文件），我们还提供了一个脚手架用于快速生成配置文件（包括自动建立机器之间的信任关系）。
相较之前，部署的速度明显的有提升，并且不再对本地网络有各种依赖，只要是能够将代码 push 到远程仓库中，后续的事情就和自己没有什么关系了，并且可以方便的进行小流量上线（部署单台验证有效性）。
以及在回滚方面则是更灵活了一些，可在多个版本之间快速切换，并且通过界面的方式，操作起来也更加直观。
最终可以说，如果没有 CI/CD，实际上开发模式也是可以忍受的，不过当使用了 CI/CD 以后，再去使用之前的部署方式，则会明显的感觉到不舒适。（没有对比，就没有伤害
#现有流程中的一些问题
在维护多个项目的时候，会暴露出一些问题：
- 如何有效的使用 测试用例
- 如何有效的使用 ESLint
- 部署上线还能再快一些吗
* 使用了 TypeScript 以后带来的额外成本
##测试用例
首先是测试用例，最初我们设计在了 git hooks 里边，在执行 git commit 之前会进行检查，在本地运行测试用例。 如果你想和更多 GitLab 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
这会带来一个时间上的问题，如果是日常开发，这么操作还是没什么问题的，但如果是线上 bug 修复，执行测试用例的时间依据项目大小可能会持续几分钟。
而为了修复 bug，可能会采用 commit 的时候添加 -n 选项来跳过 hooks，在修复 bug 时这么做无可厚非，但是即使大家在日常开发中都采用commit -n 的方式来跳过繁琐的测试过程，这个也是没有办法管控的，毕竟是在本地做的这个校验，是否遵循这个规则，全靠大家自觉。
所以一段时间后发现，通过这种方式执行测试用例来规避一些风险的作用可能并不是很有效。
##ESLint
然后就是 ESLint，我们团队基于airbnb的 ESLint 规则自定义了一套更符合团队习惯的规则，我们会在编辑器中引入插件用来帮助高亮一些错误，以及进行一些自动格式化的操作。
同时我们也在 git hooks 中添加了对应的处理，也是在 git commit 的时候进行检查，如果不符合规范则不允许提交。
不过这个与测试用例是相同的问题：
- 编辑器是否安装 ESLint 插件无从得知，即使安装插件、是否人肉忽略错误提示也无从得知。
- git hooks 可以被绕过
##部署上线的方式
之前团队的部署上线是使用shipit周边套件进行部署的。
部署环境强依赖本地，因为需要在本地建立仓库的临时目录，并经过多次ssh XXX "command"的方式完成部署 + 上线的操作。
shipit提供了一个有效的回滚方案，就是在部署后的路径添加多个历史部署版本的记录，回滚时将当前运行的项目目录指向之前的某个版本即可。（不过有一点儿坑的是，很难去选择我要回滚到那个节点，以及保存历史记录需要占用额外的磁盘空间）
不过正因为如此，shipit在部署多台服务器时会遇到一些令人不太舒服的地方。
如果是多台新增的服务器，那么可以通过在shipit配置文件中传入多个目标服务器地址来进行批量部署。
但是假设某天需要上线一些小流量（比如四台机器中的一台），因为前边提到的shipit回滚策略，这会导致单台机器与其他三台机器的历史版本时间戳不一致（因为这几台机器不是同一时间上线的）
了这个时间戳就另外提一嘴，这个时间戳的生成是基于执行上线操作的那台机器的本地时间，之前有遇到过同事在本地测试代码，将时间调整为了几天前的时间，后时间没有改回正确的时间时进行了一次部署操作，代码出现问题后却发现回滚失败了，原因是该同事部署的版本时间戳太小，shipit 找不到之前的版本（shipit 可以设置保留历史版本的数量，当时最早的一次时间戳也是大于本次出问题的时间戳的）
也就是说，哪怕有一次进行过小流量上线，那么以后就用不了批量上线的功能了 （没有去仔细研究shipit官方文档，不知道会不会有类似--force之类的忽略历史版本的操作）
基于上述的情况，我们的部署上线耗时变为了： （__机器数量__）X（__基于本地网速的仓库克隆、多次 ssh 操作的耗时总和__）。 P.S. 为了保证仓库的有效性，每次执行 shipit 部署，它都会删除之前的副本，重新克隆
尤其是服务端项目，有时紧急的 bug 修复可能是在非工作时间，这意味着可能当时你所处的网络环境并不是很稳定。
我曾经晚上接到过同事的微信，让我帮他上线项目，他家的 Wi-Fi 是某博士的，下载项目依赖的时候出了些问题。
还有过使用移动设备开热点的方式进行上线操作，有一次非前后分离的项目上线后，直接就收到了联通的短信：「您本月流量已超出XXX」（当时还在用合约套餐，一月就800M流量）。
##TypeScript
在去年下半年开始，我们团队就一直在推动 TypeScript 的应用，因为在大型项目中，拥有明确类型的 TypeScript 显然维护性会更高一些。
但是大家都知道的， TypeScript 最终需要编译转换为 JavaScript（也有 tsc 那种的不生成 JS 文件，直接运行，不过这个更多的是在本地开发时使用，线上代码的运行我们还是希望变量越少越好）。
所以之前的上线流程还需要额外的增加一步，编译 TS。
而且因为shipit是在本地克隆的仓库并完成部署的，所以这就意味着我们必须要把生成后的 JS 文件也放入到仓库中，最直观的，从仓库的概览上看着就很丑（50% TS、50% JS），同时这进一步增加了上线的成本。
总结来说，现有的部署上线流程过于依赖本地环境，因为每个人的环境不同，这相当于给部署流程增加了很多不可控因素。
#如何解决这些问题
上边我们所遇到的一些问题，其实可以分为两块：
- 有效的约束代码质量
- 快速的部署上线
所以我们就开始寻找解决方案，因为我们的源码是使用自建的 GitLab 仓库来进行管理的，首先就找到了 GitLab CI/CD。
在研究了一番文档以后发现，它能够很好的解决我们现在遇到的这些问题。
要使用 GitLab CI/CD 是非常简单的，只需要额外的使用一台服务器安装 gitlab-runner，并将要使用 CI/CD 的项目注册到该服务上就可以了。
GitLab 官方文档中有非常详细的安装注册流程：
install | runner
register | runner
group register | repo 注册 Group 项目时的一些操作
上边的注册选择的是注册 group ，也就是整个 GitLab 某个分组下所有的项目。
主要目的是因为我们这边项目数量太多，单个注册太过繁琐（还要登录到 runner 服务器去执行命令才能够注册）
##安装时需要注意的地方
官网的流程已经很详细了，不过还是有一些地方可以做一些小提示，避免踩坑。
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
这是 Linux 版本的安装命令，安装需要 root （管理员） 权限，后边跟的两个参数：
* --user 是 CI/CD 执行 job （后续所有的流程都是基于 job 的）时所使用的用户名
* --working-directory 是 CI/CD 执行时的根目录路径 个人的踩坑经验是将目录设置为一个空间大的磁盘上，因为 CI/CD 会生成大量的文件，尤其是如果使用 CI/CD 进行编译 TS 文件并且将其生成后的 JS 文件缓存；这样的操作会导致 innode 不足产生一些问题
--user 的意思就是 CI/CD 执行使用该用户进行执行，所以如果要编写脚本之类的，建议在该用户登录的状态下编写，避免出现无权限执行 sudo su gitlab-runner
##注册时需要注意的地方
在按照官网的流程执行时，我们的 tag 是留空的，暂时没有找到什么用途。
以及 executor 这个比较重要了，因为我们是从手动部署上线还是往这边靠拢的，所以稳妥的方式是一步步来，也就是说我们选择的是 shell ，最常规的一种执行方式，对项目的影响也是比较小的（官网示例给的是 Docker）。
##.gitlab-ci.yml 配置文件
上边的环境已经全部装好了，接下来就是需要让 CI/CD 真正的跑起来
runner 以哪种方式运行，就靠这个配置文件来描述了，按照约定需要将文件放置到 repo 仓库的根路径下。
当该文件存在于仓库中，执行 git push 命令后就会自动按照配置文件中所描述的动作进行执行了。
* quick start
* configuration
上边的两个链接里边信息非常完整，包含各种可以配置的选项。
一般来讲，配置文件的结构是这样的：
stages:
- stage1
- stage2
- stage3
job 1:
stage: stage1
script: echo job1
job 2:
stage: stage2
script: echo job2
job 3:
stage: stage2
script:
- echo job3-1
- echo job3-2
job 4:
stage: stage3
script: echo job4
stages 用来声明有效的可被执行的 stage，按照声明的顺序执行。
下边的那些 job XXX 名字不重要，这个名字是在 GitLab CI/CD Pipeline 界面上展示时使用的，重要的是那个 stage 属性，他用来指定当前的这一块 job 隶属于哪个 stage。
script 则是具体执行的脚本内容，如果要执行多行命令，就像job 3那种写法就好了。
如果我们将上述的 stage、job 之类的换成我们项目中的一些操作install_dependencies、test、eslint之类的，然后将script字段中的值换成类似npx eslint之类的，当你把这个文件推送到远端服务器后，你的项目就已经开始自动运行这些脚本了。
并且可以在Pipelines界面看到每一步执行的状态。
P.S. 默认情况下，上一个 stage 没有执行完时不会执行下一个 stage 的，不过也可以通过额外的配置来修改：
* allow failure
* when
设置仅在特定的情况下触发 CI/CD
上边的配置文件存在一个问题，因为在配置文件中并没有指定哪些分支的提交会触发 CI/CD 流程，所以默认的所有分支上的提交都会触发，这必然不是我们想要的结果。
CI/CD 的执行会占用系统的资源，如果因为一些开发分支的执行影响到了主干分支的执行，这是一件得不偿失的事情。
所以我们需要限定哪些分支才会触发这些流程，也就是要用到了配置中的 only 属性。
使用only可以用来设置哪些情况才会触发 CI/CD，一般我们这边常用的就是用来指定分支，这个是要写在具体的 job 上的，也就是大致是这样的操作：
具体的配置文档
job 1:
stage: stage1
script: echo job1
only:
- master
- dev
单个的配置是可以这样写的，不过如果 job 的数量变多，这么写就意味着我们需要在配置文件中大量的重复这几行代码，也不是一个很好看的事情。
所以这里可能会用到一个yaml的语法：
这是一步可选的操作，只是想在配置文件中减少一些重复代码的出现
.access_branch_template: &access_branch
only:
- master
- dev
job 1:
<<: *access_branch
stage: stage1
script: echo job1
job 2:
<<: *access_branch
stage: stage2
script: echo job2
一个类似模版继承的操作，官方文档中也没有提到，这个只是一个减少冗余代码的方式，可有可无。
##缓存必要的文件
因为默认情况下，CI/CD在执行每一步（job）时都会清理一下当前的工作目录，保证工作目录是干净的、不包含一些之前任务留下的数据、文件。
不过这在我们的 Node.js 项目中就会带来一个问题。
因为我们的 ESLint、单元测试 都是基于 node_modules 下边的各种依赖来执行的。
而目前的情况就相当于我们每一步都需要执行npm install，这显然是一个不必要的浪费。
所以就提到了另一个配置文件中的选项：cache
用来指定某些文件、文件夹是需要被缓存的，而不能清除：
cache:
key: ${CI_BUILD_REF_NAME}
paths:
- node_modules/
大致是这样的一个操作，CI_BUILD_REF_NAME是一个 CI/CD 提供的环境变量，该变量的内容为执行 CI/CD 时所使用的分支名，通过这种方式让两个分支之间的缓存互不影响。
##部署项目
如果基于上边的一些配置，我们将 单元测试、ESLint 对应的脚本放进去，他就已经能够完成我们想要的结果了，如果某一步执行出错，那么任务就会停在那里不会继续向后执行。
不过目前来看，后边已经没有多余的任务供我们执行了，所以是时候将 部署 这一步操作接过来了。
部署的话，我们目前选择的是通过 rsync 来进行同步多台服务器上的数据，一个比较简单高效的部署方式。
P.S. 部署需要额外的做一件事情，就是建立从gitlab runner所在机器gitlab-runner用户到目标部署服务器对应用户下的机器信任关系。
有 N 多种方法可以实现，最简单的就是在runner机器上执行 ssh-copy-id 将公钥写入到目标机器。
或者可以像我一样，提前将 runner 机器的公钥拿出来，需要与机器建立信任关系时就将这个字符串写入到目标机器的配置文件中。
类似这样的操作：ssh 10.0.0.1 "echo \"XXX\" >> ~/.ssh/authorized_keys"
大致的配置如下：
variables:
DEPLOY_TO: /home/XXX/repo # 要部署的目标服务器项目路径
deploy:
stage: deploy
script:
- rsync -e "ssh -o StrictHostKeyChecking=no" -arc --exclude-from="./exclude.list" --delete . 10.0.0.1:$DEPLOY_TO
- ssh 10.0.0.1 "cd $DEPLOY_TO; npm i --only=production"
- ssh 10.0.0.1 "pm2 start $DEPLOY_TO/pm2/$CI_ENVIRONMENT_NAME.json;"
同时用到的还有variables，用来提出一些变量，在下边使用。
`ssh 10.0.0.1 "pm2 start $DEPLOY_TO/pm2/$CI_ENVIRONMENT_NAME.json;"`，这行脚本的用途就是重启服务了，我们使用pm2来管理进程，默认的约定项目路径下的pm2文件夹存放着个个环境启动时所需的参数。
当然了，目前我们在用的没有这么简单，下边会统一提到。
并且在部署的这一步，我们会有一些额外的处理。
这是比较重要的一点，因为我们可能会更想要对上线的时机有主动权，所以 deploy 的任务并不是自动执行的，我们会将其修改为手动操作还会触发，这用到了另一个配置参数：
deploy:
stage: deploy
script: XXX
when: manual # 设置该任务只能通过手动触发的方式运行
当然了，如果不需要，这个移除就好了，比如说我们在测试环境就没有配置这个选项，仅在线上环境使用了这样的操作。
##更方便的管理 CI/CD 流程
如果按照上述的配置文件进行编写，实际上已经有了一个可用的、包含完整流程的 CI/CD 操作了。
不过它的维护性并不是很高，尤其是如果 CI/CD 被应用在多个项目中，想做出某项改动则意味着所有的项目都需要重新修改配置文件并上传到仓库中才能生效。
所以我们选择了一个更灵活的方式，最终我们的 CI/CD 配置文件是大致这样子的（省略了部分不相干的配置）：
variables:
SCRIPTS_STORAGE: /home/gitlab-runner/runner-scripts
DEPLOY_TO: /home/XXX/repo # 要部署的目标服务器项目路径
stages:
- install
- test
- build
- deploy_development
- deploy_production
install_dependencies:
stage: install
script: bash $SCRIPTS_STORAGE/install.sh
unit_test:
stage: test
script: bash $SCRIPTS_STORAGE/test.sh
eslint:
stage: test
script: bash $SCRIPTS_STORAGE/eslint.sh
# 编译 TS 文件
build:
stage: build
script: bash $SCRIPTS_STORAGE/build.sh
deploy_development:
stage: deploy_development
script: bash $SCRIPTS_STORAGE/deploy.sh 10.0.0.1
only: dev # 单独指定生效分支
deploy_production:
stage: deploy_production
script: bash $SCRIPTS_STORAGE/deploy.sh 10.0.0.2
only: master # 单独指定生效分支
我们将每一步 CI/CD 所需要执行的脚本都放到了 runner 那台服务器上，在配置文件中只是执行了那个脚本文件。
这样当我们有什么策略上的调整，比如说 ESLint 规则的变更、部署方式之类的。
这些都完全与项目之间进行解耦，后续的操作基本都不会让正在使用 CI/CD 的项目重新修改才能够支持（部分需要新增环境变量的导入之类的确实需要项目的支持）。
##接入钉钉通知
实际上，当 CI/CD 执行成功或者失败，我们可以在 Pipeline 页面中看到，也可以设置一些邮件通知，但这些都不是时效性很强的。
鉴于我们目前在使用钉钉进行工作沟通，所以就研究了一波钉钉机器人。
发现有支持 GitLab 机器人，不过功能并不适用，只能处理一些 issues 之类的， CI/CD 的一些通知是缺失的，所以只好自己基于钉钉的消息模版实现一下了。
因为上边我们已经将各个步骤的操作封装了起来，所以这个修改对同事们是无感知的，我们只需要修改对应的脚本文件，添加钉钉的相关操作即可完成，封装了一个简单的函数：
function sendDingText() {
local text="$1"
curl -X POST "$DINGTALK_HOOKS_URL" \
-H 'Content-Type: application/json' \
-d '{
"msgtype": "text",
"text": {
"content": "'"$text"'"
}
}'
}
# 具体发送时传入的参数
sendDingText "proj: $CI_PROJECT_NAME[$CI_JOB_NAME]\nenv: $CI_ENVIRONMENT_NAME\ndeploy success\n$CI_PIPELINE_URL\ncreated by: $GITLAB_USER_NAME\nmessage: $CI_COMMIT_MESSAGE"
# 某些 case 失败的情况下 是否需要更多的信息就看自己自定义咯
sendDingText "error: $CI_PROJECT_NAME[$CI_JOB_NAME]\nenv: $CI_ENVIRONMENT_NAME"上述用到的环境变量，除了DINGTALK_HOOKS_URL是我们自定义的机器人通知地址以外，其他的变量都是有 GitLab runenr所提供的。
各种变量可以从这里找到：predefined variables
##回滚处理
聊完了正常的流程，那么也该提一下出问题时候的操作了。
人非圣贤孰能无过，很有可能某次上线一些没有考虑到的地方就会导致服务出现异常，这时候首要任务就是让用户还可以照常访问，所以我们会选择回滚到上一个有效的版本去。
在项目中的 Pipeline 页面 或者 Enviroment 页面（这个需要在配置文件中某些 job 中手动添加这个属性，一般会写在 deploy 的那一步去），可以在页面上选择想要回滚的节点，然后重新执行 CI/CD 任务，即可完成回滚。
不过这在 TypeScript 项目中会有一些问题，因为我们回滚一般来讲是重新执行上一个版本 CI/CD 中的 deploy 任务，在 TS 项目中，我们在 runner 中缓存了 TS 转换 JS 之后的 dist 文件夹，并且部署的时候也是直接将该文件夹推送到服务器的（TS项目的源码就没有再往服务器上推过了）。
而如果我们直接点击 retry 就会带来一个问题，因为我们的 dist 文件夹是缓存的，而 deploy 并不会管这种事儿，他只会把对应的要推送的文件发送到服务器上，并重启服务。
而实际上 dist 还是最后一次（也就是出错的那次）编译出来的 JS 文件，所以解决这个问题有两种方法：
- 在 deploy 之前执行一下 build
- 在 deploy 的时候进行判断
第一个方案肯定是不可行的，因为严重依赖于操作上线的人是否知道有这个流程。
所以我们主要是通过第二种方案来解决这个问题。
我们需要让脚本在执行的时候知道，dist 文件夹里边的内容是不是自己想要的。
所以就需要有一个 __标识__，而做这个标识最简单有效唾手可得的就是，git commit id。
每一个 commit 都会有一个唯一的标识符号，而且我们的 CI/CD 执行也是依靠于新代码的提交（也就意味着一定有 commit）。
所以我们在 build 环节将当前的commit id也缓存了下来：
git rev-parse --short HEAD > git_version
同时在 deploy 脚本中添加额外的判断逻辑：
currentVersion=`git rev-parse --short HEAD`
tagVersion=`touch git_version; cat git_version`
if [ "$currentVersion" = "$tagVersion" ]
then
echo "git version match"
else
echo "git version not match, rebuild dist"
bash ~/runner-scripts/build.sh # 额外的执行 build 脚本
fi
这样一来，就避免了回滚时还是部署了错误代码的风险。
关于为什么不将 build 这一步操作与 deploy 合并的原因是这样的：
因为我们会有很多台机器，同时 job 会写很多个，类似 deploy_1、deploy_2、deploy_all，如果我们将 build 的这一步放到 deploy 中。
那就意味着我们每次 deploy，即使是一次部署，但因为我们选择一台台机器单独操作，它也会重新生成多次，这也会带来额外的时间成本。
##hot fix 的处理
在 CI/CD 运行了一段时间后，我们发现偶尔解决线上 bug 还是会比较慢，因为我们提交代码后要等待完整的 CI/CD 流程走完。
所以在研究后我们决定，针对某些特定情况hot fix，我们需要跳过ESLint、单元测试这些流程，快速的修复代码并完成上线。
CI/CD 提供了针对某些 Tag 可以进行不同的操作，不过我并不想这么搞了，原因有两点：
- 这需要修改配置文件（所有项目）
- 这需要开发人员熟悉对应的规则（打 Tag）
所以我们采用了另一种取巧的方式来实现，因为我们的分支都是只接收Merge Request那种方式上线的，所以他们的commit title实际上是固定的：Merge branch 'XXX'。
同时 CI/CD 会有环境变量告诉我们当前执行 CI/CD 的 commit message。
我们通过匹配这个字符串来检查是否符合某种规则来决定是否跳过这些job：
function checkHotFix() {
local count=`echo $CI_COMMIT_TITLE | grep -E "^Merge branch '(hot)?fix/\w+" | wc -l`
if [ $count -eq 0 ]
then
return 0
else
return 1
fi
}
# 使用方法
checkHotFix
if [ $? -eq 0 ]
then
echo "start eslint"
npx eslint --ext .js,.ts .
else
# 跳过该步骤
echo "match hotfix, ignore eslint"
fi这样能够保证如果我们的分支名为 hotfix/XXX 或者 fix/XXX 在进行代码合并时， CI/CD 会跳过多余的代码检查，直接进行部署上线。 没有跳过安装依赖的那一步，因为 TS 编译还是需要这些工具的。
#小结
目前团队已经有超过一半的项目接入了 CI/CD 流程，为了方便同事接入（主要是编辑 .gitlab-ci.yml 文件），我们还提供了一个脚手架用于快速生成配置文件（包括自动建立机器之间的信任关系）。
相较之前，部署的速度明显的有提升，并且不再对本地网络有各种依赖，只要是能够将代码 push 到远程仓库中，后续的事情就和自己没有什么关系了，并且可以方便的进行小流量上线（部署单台验证有效性）。
以及在回滚方面则是更灵活了一些，可在多个版本之间快速切换，并且通过界面的方式，操作起来也更加直观。
最终可以说，如果没有 CI/CD，实际上开发模式也是可以忍受的，不过当使用了 CI/CD 以后，再去使用之前的部署方式，则会明显的感觉到不舒适。（没有对比，就没有伤害
在Kubernetes上运行Kafka合适吗？
whole 发表了文章 • 0 个评论 • 374 次浏览 • 2019-06-02 11:42
【编者的话】本文介绍了在Kubernetes运行Kafka的互补性和一些坑，以及相关方案选择。
# 介绍
Kubernetes设计的初衷是运行无状态工作负载。这些通常采用微服务架构的工作负载，是轻量级，可水平扩展，遵循十二要素应用程序， ...查看全部
【编者的话】本文介绍了在Kubernetes运行Kafka的互补性和一些坑，以及相关方案选择。
# 介绍
Kubernetes设计的初衷是运行无状态工作负载。这些通常采用微服务架构的工作负载，是轻量级，可水平扩展，遵循十二要素应用程序，可以处理环形断路和随机Monkey测试。
另一方面，Kafka本质上是一个分布式数据库。这意味着你必须处理状态，它比微服务更重量级。Kubernetes支持有状态的工作负载，但你必须谨慎对待它，正如Kelsey Hightower在最近的两条推文中指出的那样：
现在你应该在Kubernetes上运行Kafka吗？我的反问是：没有它，Kafka会跑得更好吗？这就是为什么我要指出Kafka和Kubernetes之间的相互补充性以及你可能遇到的陷阱。
# 运行时
让我们先看一下基本的东西——运行时本身。
## 进程
Kafka brokers对CPU很友好。TLS可能会引入一些开销。如果Kafka客户端使用加密，则需要更多CPU，但这不会影响brokers。如果你想和更多Kubernetes技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
## 内存
Kafka brokers是内存消耗大户。JVM堆通常可以限制为4-5 GB，但由于Kafka大量使用页面缓存，因此还需要足够的系统内存。在Kubernetes中，可以相应地设置容器资源限制和请求。
## 存储
容器中的存储是短暂的——重启后数据将丢失。可以对Kafka数据使用emptyDir卷，这将产生相同的效果：brokers的数据将在停机后丢失。您的消息在其他broker上作为副本还是可以使用的。因此，重新启动后，失败的broker必须得复制所有的数据，这可能是一个耗时过程。
这就是你应该使用持久存储的原因。使用XFS或ext4的非本地持久性块存储更合适。我警告你：不要使用NFS。NFS v3和v4都不会起作用。简而言之，Kafka broker会因为NFS“愚蠢重命名”问题而无法删除数据目录，自行终止。如果你仍然不相信我，那么请仔细阅读这篇博文。存储必须是非本地的，以便Kubernetes在重新启动或重新定位时可以更灵活地选择另一个节点。
## 网络
与大多数分布式系统一样，Kafka性能在很大程度上取决于低网络延迟和高带宽。不要试图将所有代理放在同一节点上，因为这会降低可用性。如果Kubernetes节点出现故障，那么整个Kafka集群都会出现故障。不要跨数据中心扩展Kafka集群。这同样适用于Kubernetes集群。不同的可用区域是一个很好的权衡。
# 配置
## 清单
Kubernetes网站包含一个非常好的教程，介绍如何使用清单设置ZooKeeper。由于ZooKeeper是Kafka的一部分，因此可以通过这个了解哪些Kubernetes概念被应用在这里。一旦理解，您也可以对Kafka集群使用相同的概念。
Yolean提供了一套全面的清单，可以帮助您开始使用Kubernetes上的Kafka。
## Helm Charts
Helm是Kubernetes的包管理器，类似yum，apt，Homebrew或Chocolatey等OS包管理器。它允许您安装Helm Charts中描述的预定义软件包。精心设计的Helm Charts能简化所有参数正确配置的复杂任务，以便在Kubernetes上运行Kafka。有几张图表适用于Kafka的的可供选择：一个是处于演进状态的官方图表，一个来自Confluent，另一个来自Bitnami，仅举几例。
## Operators
由于Helm的一些限制，另一种工具变得非常流行：Kubernetes Operators。Operators不仅可以为Kubernetes打包软件，还可以为Kubernetes部署和管理一个软件。
评价很高的Operators名单中提到Kafka有两个，其中一个是Strimzi，Strimzi使得在几分钟内启动Kafka集群变得非常容易，几乎不需要任何配置，它增加了一些漂亮的功能，如群集间点对点TLS加密。Confluent还宣布即将推出新的Operator。
## 性能
运行性能测试以对Kafka安装进行基准测试非常重要。在您遇到麻烦之前，它会为您提供有关可能的瓶颈的地方。幸运的是，Kafka已经提供了两个性能测试工具：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。记得经常使用它们。作为参考，可以使用Jay Kreps的博客结果，或者 Stéphane Maarek在 Amazon MSK的评论。
# 运维
## 监控
可见性非常重要，否则您将不知道发生了什么。如今，有一种不错的工具可以用云原生方式监控指标。Prometheus和Grafana是两种流行的工具。Prometheus可以直接从JMX导出器收集所有Java进程（Kafka，ZooKeeper，Kafka Connect）的指标。添加cAdvisor指标可为提供有关Kubernetes资源使用情况的其他信息。
Strimzi为Kafka提供了一个优雅的Grafana仪表板示例。它以非常直观的方式可视化关键指标，如未复制的和离线分区。它通过资源使用和性能以及稳定性指标来补充这些指标。因此，可以免费获得基本的Kafka集群监控！
资料来源：https://strimzi.io/docs/master/#kafka_dashboard
可以通过客户端监控（消费者和生产者指标），使用Burrow滞后监控，使用Kafka Monitor进行端到端监控，来完成这个任务
## 日志记录
日志记录是另一个关键部分。确保Kafka安装中的所有容器都记录到标准输出（stdout）和标准错误输出（stderr），并确保Kubernetes集群将所有日志聚合到中央日志记录设施中如Elasticsearch中。
## 健康检查
Kubernetes使用活跃度和就绪探测器来确定Pod是否健康。如果活跃度探测失败，Kubernetes将终止容器并在相应设置重启策略时自动重启。如果准备就绪探测失败，那么Kubernetes将通过服务从服务请求中删除该Pod。这意味着在这种情况下不再需要人工干预，这是一大优点。
## 滚动更新
StatefulSets支持自动更新：滚动更新策略将一次更新一个Kafka Pod。通过这种方式，可以实现零停机时间，这是Kubernetes带来的另一大优势。
## 扩展
扩展Kafka集群并非易事。但是，Kubernetes可以很容易地将Pod缩放到一定数量的副本，这意味着可以声明式地定义所需数量的Kafka brokers。困难的部分是在放大或缩小之前重新分配部分。同样，Kubernetes可以帮助您完成这项任务。
## 管理
通过在Pod中打开shell，可以使用现有的shell脚本完成Kafka群集的管理任务，例如创建主题和重新分配分区。这不是一个很好的解决方案。Strimzi支持与另一个Operator管理主题。这还有改进的余地。
## 备份和还原
现在Kafka的可用性还取决于Kubernetes的可用性。如果Kubernetes群集出现故障，那么在最坏的情况下Kafka群集也会故障。墨菲定律告诉我们，这也会发生在你身上，你会丢失数据。要降低此风险，请确保您具有备份想法。MirrorMaker是一种可选方案，另一种可能是利用S3进行连接备份，如Zalando的博客文章所述。
# 结论
对于中小型Kafka集群，我肯定会选择Kubernetes，因为它提供了更大的灵活性并简化了操作。如果您在延迟和/或吞吐量方面具有非常高的非功能性要求，则不同的部署选项可能更有益。
原文链接：Kafka on Kubernetes — a good fit?（译者：姜俊厚）
# 介绍
Kubernetes设计的初衷是运行无状态工作负载。这些通常采用微服务架构的工作负载，是轻量级，可水平扩展，遵循十二要素应用程序，可以处理环形断路和随机Monkey测试。
另一方面，Kafka本质上是一个分布式数据库。这意味着你必须处理状态，它比微服务更重量级。Kubernetes支持有状态的工作负载，但你必须谨慎对待它，正如Kelsey Hightower在最近的两条推文中指出的那样：
现在你应该在Kubernetes上运行Kafka吗？我的反问是：没有它，Kafka会跑得更好吗？这就是为什么我要指出Kafka和Kubernetes之间的相互补充性以及你可能遇到的陷阱。
# 运行时
让我们先看一下基本的东西——运行时本身。
## 进程
Kafka brokers对CPU很友好。TLS可能会引入一些开销。如果Kafka客户端使用加密，则需要更多CPU，但这不会影响brokers。如果你想和更多Kubernetes技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
## 内存
Kafka brokers是内存消耗大户。JVM堆通常可以限制为4-5 GB，但由于Kafka大量使用页面缓存，因此还需要足够的系统内存。在Kubernetes中，可以相应地设置容器资源限制和请求。
## 存储
容器中的存储是短暂的——重启后数据将丢失。可以对Kafka数据使用emptyDir卷，这将产生相同的效果：brokers的数据将在停机后丢失。您的消息在其他broker上作为副本还是可以使用的。因此，重新启动后，失败的broker必须得复制所有的数据，这可能是一个耗时过程。
这就是你应该使用持久存储的原因。使用XFS或ext4的非本地持久性块存储更合适。我警告你：不要使用NFS。NFS v3和v4都不会起作用。简而言之，Kafka broker会因为NFS“愚蠢重命名”问题而无法删除数据目录，自行终止。如果你仍然不相信我，那么请仔细阅读这篇博文。存储必须是非本地的，以便Kubernetes在重新启动或重新定位时可以更灵活地选择另一个节点。
## 网络
与大多数分布式系统一样，Kafka性能在很大程度上取决于低网络延迟和高带宽。不要试图将所有代理放在同一节点上，因为这会降低可用性。如果Kubernetes节点出现故障，那么整个Kafka集群都会出现故障。不要跨数据中心扩展Kafka集群。这同样适用于Kubernetes集群。不同的可用区域是一个很好的权衡。
# 配置
## 清单
Kubernetes网站包含一个非常好的教程，介绍如何使用清单设置ZooKeeper。由于ZooKeeper是Kafka的一部分，因此可以通过这个了解哪些Kubernetes概念被应用在这里。一旦理解，您也可以对Kafka集群使用相同的概念。
- Pod：Pod是Kubernetes中最小的可部署单元。它包含您的工作负载，它代表群集中的一个进程。一个Pod包含一个或多个容器。整体中的每个ZooKeeper服务器和Kafka集群中的每个Kafka broker都将在一个单独的Pod中运行。
- StatefulSet：StatefulSet是一个Kubernetes对象，用于处理需要协调的多个有状态工作负载。StatefulSets保证Pod的有序性和唯一性的。
- Headless Services：服务通过逻辑名称将Pod与客户端分离。Kubernetes负责负载平衡。但是，对于ZooKeeper和Kafka等有状态工作负载，客户端必须与特定实例进行通信。这就是 Headless Services发挥作用的地方：作为客户端，仍然可以获得逻辑名称，但不必直接访问Pod。
- 持久卷：如上所述，需要配置非本地持久块存储。
Yolean提供了一套全面的清单，可以帮助您开始使用Kubernetes上的Kafka。
## Helm Charts
Helm是Kubernetes的包管理器，类似yum，apt，Homebrew或Chocolatey等OS包管理器。它允许您安装Helm Charts中描述的预定义软件包。精心设计的Helm Charts能简化所有参数正确配置的复杂任务，以便在Kubernetes上运行Kafka。有几张图表适用于Kafka的的可供选择：一个是处于演进状态的官方图表，一个来自Confluent，另一个来自Bitnami，仅举几例。
## Operators
由于Helm的一些限制，另一种工具变得非常流行：Kubernetes Operators。Operators不仅可以为Kubernetes打包软件，还可以为Kubernetes部署和管理一个软件。
评价很高的Operators名单中提到Kafka有两个，其中一个是Strimzi，Strimzi使得在几分钟内启动Kafka集群变得非常容易，几乎不需要任何配置，它增加了一些漂亮的功能，如群集间点对点TLS加密。Confluent还宣布即将推出新的Operator。
## 性能
运行性能测试以对Kafka安装进行基准测试非常重要。在您遇到麻烦之前，它会为您提供有关可能的瓶颈的地方。幸运的是，Kafka已经提供了两个性能测试工具：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。记得经常使用它们。作为参考，可以使用Jay Kreps的博客结果，或者 Stéphane Maarek在 Amazon MSK的评论。
# 运维
## 监控
可见性非常重要，否则您将不知道发生了什么。如今，有一种不错的工具可以用云原生方式监控指标。Prometheus和Grafana是两种流行的工具。Prometheus可以直接从JMX导出器收集所有Java进程（Kafka，ZooKeeper，Kafka Connect）的指标。添加cAdvisor指标可为提供有关Kubernetes资源使用情况的其他信息。
Strimzi为Kafka提供了一个优雅的Grafana仪表板示例。它以非常直观的方式可视化关键指标，如未复制的和离线分区。它通过资源使用和性能以及稳定性指标来补充这些指标。因此，可以免费获得基本的Kafka集群监控！
资料来源：https://strimzi.io/docs/master/#kafka_dashboard
可以通过客户端监控（消费者和生产者指标），使用Burrow滞后监控，使用Kafka Monitor进行端到端监控，来完成这个任务
## 日志记录
日志记录是另一个关键部分。确保Kafka安装中的所有容器都记录到标准输出（stdout）和标准错误输出（stderr），并确保Kubernetes集群将所有日志聚合到中央日志记录设施中如Elasticsearch中。
## 健康检查
Kubernetes使用活跃度和就绪探测器来确定Pod是否健康。如果活跃度探测失败，Kubernetes将终止容器并在相应设置重启策略时自动重启。如果准备就绪探测失败，那么Kubernetes将通过服务从服务请求中删除该Pod。这意味着在这种情况下不再需要人工干预，这是一大优点。
## 滚动更新
StatefulSets支持自动更新：滚动更新策略将一次更新一个Kafka Pod。通过这种方式，可以实现零停机时间，这是Kubernetes带来的另一大优势。
## 扩展
扩展Kafka集群并非易事。但是，Kubernetes可以很容易地将Pod缩放到一定数量的副本，这意味着可以声明式地定义所需数量的Kafka brokers。困难的部分是在放大或缩小之前重新分配部分。同样，Kubernetes可以帮助您完成这项任务。
## 管理
通过在Pod中打开shell，可以使用现有的shell脚本完成Kafka群集的管理任务，例如创建主题和重新分配分区。这不是一个很好的解决方案。Strimzi支持与另一个Operator管理主题。这还有改进的余地。
## 备份和还原
现在Kafka的可用性还取决于Kubernetes的可用性。如果Kubernetes群集出现故障，那么在最坏的情况下Kafka群集也会故障。墨菲定律告诉我们，这也会发生在你身上，你会丢失数据。要降低此风险，请确保您具有备份想法。MirrorMaker是一种可选方案，另一种可能是利用S3进行连接备份，如Zalando的博客文章所述。
# 结论
对于中小型Kafka集群，我肯定会选择Kubernetes，因为它提供了更大的灵活性并简化了操作。如果您在延迟和/或吞吐量方面具有非常高的非功能性要求，则不同的部署选项可能更有益。
原文链接：Kafka on Kubernetes — a good fit?（译者：姜俊厚）
学好Docker，你应该了解这些
老马 发表了文章 • 0 个评论 • 265 次浏览 • 2019-05-30 20:07
Docker公司推出的三剑客：Machine、Compose和Swarm。这三件利器的出现，让Docker不仅支持单机的虚拟化，而且能支持更广泛的集群平台，提供更强大灵活的功能。本文通过简短的介绍，让对Docker三剑客有个初步了解。今后遇到Docker相关问 ...查看全部
Docker公司推出的三剑客：Machine、Compose和Swarm。这三件利器的出现，让Docker不仅支持单机的虚拟化，而且能支持更广泛的集群平台，提供更强大灵活的功能。本文通过简短的介绍，让对Docker三剑客有个初步了解。今后遇到Docker相关问题，知道用什么技术去解决。
docker-machine：解决Docker运行环境问题。
Docker技术是基于Linux内核的cgroup技术实现的，那么问题来了，如果在非Linux平台上使用Docker技术需要依赖安装Linux系统的虚拟机。docker-machine就是Docker公司官方提出的，用于在各种平台上快速创建具有Docker服务的虚拟机的技术。可以把它理解为virtualbox或者VMware，最开始在Win7上用得比较多，但是Win10开始自带了hyper-v虚拟机，已经不再需要docker-machine了，Docker可以直接运行在安装了Linux系统得hyper-v上。
dcoker-compose：解决本地Docker容器编排问题。
一般是通过yaml配置文件来使用它，这个docker-compose.yml文件里能记录多个容器启动的配置信息（镜像、启动命令、端口映射等），最后只需要执行docker-compose对应的命令，例如docker-compose up就会像执行脚本一样地批量创建和销毁容器。
docker-swarm：解决多主机多个容器调度部署得问题。
Swarm是基于Docker平台实现的集群技术，他可以通过几条简单的指令快速的创建一个Docker集群，接着在集群的共享网络上部署应用，最终实现分布式的服务。Swarm技术不是很成熟，很多配置功能都无法实现，只能说是个半成品，目前更多的是使用Kubernetes来管理集群和调度容器。如果你想和更多Docker技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
总结
如果你是在非Linux环境下考虑使用docker-machine，当然我更推荐使用hyper-v或者virtualbox。如果你需要同时操作多个容器，或者希望使用配置文件记录容器启动命令参数，那么推荐使用docker-compose。如果你需要在多台主机上部署Docker容器，并对其进行调度，那么Swarm是一种选择，当然更推荐Kubernetes。
原文链接：https://www.jianshu.com/p/b293d076b34b
docker-machine：解决Docker运行环境问题。
Docker技术是基于Linux内核的cgroup技术实现的，那么问题来了，如果在非Linux平台上使用Docker技术需要依赖安装Linux系统的虚拟机。docker-machine就是Docker公司官方提出的，用于在各种平台上快速创建具有Docker服务的虚拟机的技术。可以把它理解为virtualbox或者VMware，最开始在Win7上用得比较多，但是Win10开始自带了hyper-v虚拟机，已经不再需要docker-machine了，Docker可以直接运行在安装了Linux系统得hyper-v上。
dcoker-compose：解决本地Docker容器编排问题。
一般是通过yaml配置文件来使用它，这个docker-compose.yml文件里能记录多个容器启动的配置信息（镜像、启动命令、端口映射等），最后只需要执行docker-compose对应的命令，例如docker-compose up就会像执行脚本一样地批量创建和销毁容器。
docker-swarm：解决多主机多个容器调度部署得问题。
Swarm是基于Docker平台实现的集群技术，他可以通过几条简单的指令快速的创建一个Docker集群，接着在集群的共享网络上部署应用，最终实现分布式的服务。Swarm技术不是很成熟，很多配置功能都无法实现，只能说是个半成品，目前更多的是使用Kubernetes来管理集群和调度容器。如果你想和更多Docker技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
总结
如果你是在非Linux环境下考虑使用docker-machine，当然我更推荐使用hyper-v或者virtualbox。如果你需要同时操作多个容器，或者希望使用配置文件记录容器启动命令参数，那么推荐使用docker-compose。如果你需要在多台主机上部署Docker容器，并对其进行调度，那么Swarm是一种选择，当然更推荐Kubernetes。
原文链接：https://www.jianshu.com/p/b293d076b34b
Git 自救指南
Andy_Lee 发表了文章 • 0 个评论 • 153 次浏览 • 2019-05-30 19:57
Git 虽然因其分布式管理方式，不完全依赖网络，良好的分支策略，容易部署等优点，已经成为最受欢迎的源代码管理方式。但是一分耕耘一分收获，如果想更好地掌握 Git，需要付出大量的学习成本。即使在各种 GUI 的加持下，也不得不说 Git 真的很难，在 V2EX ...查看全部
Git 虽然因其分布式管理方式，不完全依赖网络，良好的分支策略，容易部署等优点，已经成为最受欢迎的源代码管理方式。但是一分耕耘一分收获，如果想更好地掌握 Git，需要付出大量的学习成本。即使在各种 GUI 的加持下，也不得不说 Git 真的很难，在 V2EX 上也常有如何正确使用 Git 的讨论，同时在 Stackoverflow 上超过 10w+ 的 Git 相关问题也证明了 Git 的复杂性。再加上 Git 的官方文档也一直存在着 “先有鸡还是先有蛋” 的问题，虽然文档非常全面，但如果你不知道你遇到的问题叫什么，那么根本就无从查起。
本文节选自 Katie Sylor-Miller 在日常工作中所遇到过的让他很头疼的 Git 相关问题，并整理了相应的应对措施，在这里分享给正在学习如何使用 Git 的同学们。当然这些应对措施并不是唯一的，可能你会有其他更好的应对方法，这也恰恰是 Git 这套版本控制系统强大的地方。如果你想和更多 Git 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
我刚刚好像搞错了一个很重要的东西，但是 Git 有个神奇的时间机器能帮我复原！
reflog 是一个非常实用的命令，你可以使用这个命令去找回无意间删除的代码，或者去掉一些刚刚添加的却把仓库里的代码弄坏的内容。同时也可以拯救一下失败的 merge，或者仅仅是为了回退到之前的版本。
我 commit 完才想起来还有一处小地方要修改！
当我 commit 完然后跑测试的时候，经常突然发现忘了在等于号前面加空格。虽然可以把修改过的代码再重新 commit 一下，然后 rebase -i 将两次揉在一起，不过上面的方法会比较快。
我要改一下上一个 commit message！
当你们组对 commit message 有格式要求时，或者当你忘了中英文间要加空格，这个命令能救你狗命。
我不小心把本应在新分支上的内容 commit 到 master 了！
注意：这个指令必须在错误的 commit 后直接执行，如果你已经试了其他的方式，你可能就需要用 git reset HEAD@{number} 来代替 HEAD~ 了。
我不小心 commit 到错误的分支上了！
也有很多人推荐了 cherry-pick 的解决方案，所以选哪个就看你心情了。
我执行了 diff 但是啥也没出现
Git 不会给通过 add 加入到 staging 区域里面的文件做 diff ，除非你加了 --staged 的标签，别怀疑了这是一个 feature 不是一个 bug，当然对于第一次碰到这个问题的人来说还是有些不好理解的。
Git 从入门到放弃
为了维护最后的尊严 XD
原文链接：https://mp.weixin.qq.com/s/kr0KrwpueC73PD8Ma_AuWg
本文节选自 Katie Sylor-Miller 在日常工作中所遇到过的让他很头疼的 Git 相关问题，并整理了相应的应对措施，在这里分享给正在学习如何使用 Git 的同学们。当然这些应对措施并不是唯一的，可能你会有其他更好的应对方法，这也恰恰是 Git 这套版本控制系统强大的地方。如果你想和更多 Git 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
我刚刚好像搞错了一个很重要的东西，但是 Git 有个神奇的时间机器能帮我复原！
git reflog
# you will see a list of every thing you've done in git, across all branches!
# each one has an index HEAD@{index}
# find the one before you broke everything
git reset HEAD@{index}
# magic time machine
reflog 是一个非常实用的命令，你可以使用这个命令去找回无意间删除的代码，或者去掉一些刚刚添加的却把仓库里的代码弄坏的内容。同时也可以拯救一下失败的 merge，或者仅仅是为了回退到之前的版本。
我 commit 完才想起来还有一处小地方要修改！
# make your change
git add . # or add individual files
git commit --amend
# follow prompts to change or keep the commit message
# now your last commit contains that change!
当我 commit 完然后跑测试的时候，经常突然发现忘了在等于号前面加空格。虽然可以把修改过的代码再重新 commit 一下，然后 rebase -i 将两次揉在一起，不过上面的方法会比较快。
我要改一下上一个 commit message！
git commit --amend
# follow prompts to change the commit message
当你们组对 commit message 有格式要求时，或者当你忘了中英文间要加空格，这个命令能救你狗命。
我不小心把本应在新分支上的内容 commit 到 master 了！
# create a new branch from the current state of master
git branch some-new-branch-name
# remove the commit from the master branch
git reset HEAD~ --hard
git checkout some-new-branch-name
# your commit lives in this branch now :)
注意：这个指令必须在错误的 commit 后直接执行，如果你已经试了其他的方式，你可能就需要用 git reset HEAD@{number} 来代替 HEAD~ 了。
我不小心 commit 到错误的分支上了！
# undo the last commit, but leave the changes available
git reset HEAD~ --soft
git stash
# move to the correct branch
git checkout name-of-the-correct-branch
git stash pop
git add . # or add individual files
git commit -m "your message here"
# now your changes are on the correct branch
也有很多人推荐了 cherry-pick 的解决方案，所以选哪个就看你心情了。
git checkout name-of-the-correct-branch
# grab the last commit to master
git cherry-pick master
# delete it from master
git checkout master
git reset HEAD~ --hard
我执行了 diff 但是啥也没出现
git diff --staged
Git 不会给通过 add 加入到 staging 区域里面的文件做 diff ，除非你加了 --staged 的标签，别怀疑了这是一个 feature 不是一个 bug，当然对于第一次碰到这个问题的人来说还是有些不好理解的。
Git 从入门到放弃
cd ..
sudo rm -r fucking-git-repo-dir
git clone https://some.github.url/fucking-git-repo-dir.git
cd fucking-git-repo-dir
为了维护最后的尊严 XD
原文链接：https://mp.weixin.qq.com/s/kr0KrwpueC73PD8Ma_AuWg
如何限制Kubernetes本地临时存储的容量
aoxiang 发表了文章 • 0 个评论 • 276 次浏览 • 2019-05-30 19:02
#介绍
作为Kubernetes平台的提供方，必须要对某些“流氓”应用做出一些限制，防止它们滥用平台的CPU、内存、磁盘、网络等资源。
例如，Kubernetes提供了对CPU，内存的限制，可以防止应用无限制的使用系统的资 ...查看全部
#介绍
作为Kubernetes平台的提供方，必须要对某些“流氓”应用做出一些限制，防止它们滥用平台的CPU、内存、磁盘、网络等资源。
例如，Kubernetes提供了对CPU，内存的限制，可以防止应用无限制的使用系统的资源；Kubernetes提供的PVC，如CephFS、RBD，也支持容量的限制。
但是，早期Kubernetes版本并没有限制container的rootfs的容量，由于默认容器使用的log存储空间是在 /var/lib/kubelet/ 下，rootfs在/var/lib/docker下，而这两个目录默认就在宿主机Node的根分区，如果应用恶意攻击，可以通过在容器内大量dd从而迅速造成宿主机Node根分区文件系统满。我们知道，当Linux根分区使用达到100%的时候，通常会很危险。
Kubernetes在1.8版本引入了一种新的resource：local ephemeral storage（临时存储），用来管理本地临时存储，对应特性 LocalStorageCapacityIsolation。从1.10开始该特性转为beta状态，默认开启。如果你想和更多 Kubernetes 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
临时存储，如emptyDir volumes, container logs，image layers and container writable layers，默认它们使用的是 /var/lib/kubelet，通过限制临时存储容量，也就可以保护Node的root分区了。
本地临时存储管理只对root分区有效，如果你定制了相关的参数，例如 --root-dir，则不会生效。
#配置
我的集群版本是1.14，默认开启了 local ephemeral storage 的特性，只需要配置Pod即可。
Pod的每个container都可以配置：
* spec.containers[].resources.limits.ephemeral-storage
* spec.containers[].resources.requests.ephemeral-storage
单位是byte，可以直接配置，也可以按E/P/T/G/M/K或者Ei, Pi, Ti, Gi, Mi, Ki.为单位来配置，例如 128974848, 129e6, 129M, 123Mi 表示的是同一个容量。
下面创建一个Deployment，设置其使用的临时存储最大为2Gi。
Pod启动后，进入容器，执行dd if=/dev/zero of=/test bs=4096 count=1024000 ，尝试创建一个4Gi的文件，可以发现在执行一段时间后，Pod被 Evict，controller重新创建了新的Pod。
#实现
Evict Pod动作是由kubelet完成的。每个节点上的kubelet会启动一个evict manager，每10秒种(evictionMonitoringPeriod)进行一次检查，ephemeral storage的检查也是在这个阶段完成的。
evict manager可以对pod和container来检查超额应用。
其中Pod为GetActivePods获取的本节点所有非Terminated状态的Pod。
kubelet会依此检查Pod的emptyDir、Pod级临时存储、container级临时存储，若Pod需要被evict，则加到evicted数组，之后会将evicted的Pod挤出。
contaier级检查比较简单，因为ephemeral storage设置的就是在container上，依次检查container的使用情况和设置的limits，如果超过了limits，则要加入到evicted pods列表中。
相关代码在 containerEphemeralStorageLimitEviction 中。
而Pod级别的检查会复杂一点。
首先是限制值的计算。
kubelet会统计Pod所有container（但不包括init container）的ephemeral storage limits之和。init container指定的是Pod的配额最低需求（有点像最低工资标准，用于生活保障），当所有container指定的配额，超过init container指定的配额时，将忽略init container指定的配额。数学描述如下。
而实际临时存储用量的计算，除了会计算指定过ephemeral storage的container的使用量，还会统计未指定过ephemeral storage的container，以及emptyDir的使用量。
当实际临时存储用量，超过了限制值时，kubelet会将该Pod Evict，然后等待controller重新创建新的Pod并重新调度。
相关代码在 podEphemeralStorageLimitEviction 中。
#requests
注意，设置的local ephemeralstorage requests在evict manager处理过程中没有用到。但是它不是没用的。
创建Pod后，scheduler会将该Pod调度到集群中某个node上。由于每个node所能承载的local ephemeral storage是有上限的，所以scheduler会保证该node上所有Pod的 local ephemeralstorage requests 总和不会超过node的根分区容量。
#inode 保护
有的时候，我们会发现磁盘写入时会报磁盘满，但是df查看容量并没有100%使用，此时可能只是因为inode耗尽造成的。因此，对平台来说，inode的保护也是需要的。
其中，podLocalEphemeralStorageUsage 也统计了container或者pods使用的inode的数量。
但是当前Kubernetes并不支持对Pod的临时存储设置inode的limits/requests。
当然了，如果node进入了inode紧缺的状态，kubelet会将node设置为 under pressure，不再接收新的Pod请求。
#emptyDir
emptyDir也是一种临时存储，因此也需要限制使用。
在Pod级别检查临时存储使用量时，也会将emptyDir的使用量计算在内，因此如果对emptyDir使用过量后，也会导致该Pod被kubelet Evict。
另外，emptyDir本身也可以设置容量上限。如下所摘录编排文件片段，我指定了emptyDir使用内存作为存储介质，这样用户可以获得极好的读写性能，但是由于内存比较珍贵，我只提供了64Mi的空间，当用户在 /cache 目录下使用超过64Mi后，该Pod会被kubelet evict。
相关代码在 emptyDirLimitEviction 中。
原文链接：https://ieevee.com/tech/2019/05/23/ephemeral-storage.html
作为Kubernetes平台的提供方，必须要对某些“流氓”应用做出一些限制，防止它们滥用平台的CPU、内存、磁盘、网络等资源。
例如，Kubernetes提供了对CPU，内存的限制，可以防止应用无限制的使用系统的资源；Kubernetes提供的PVC，如CephFS、RBD，也支持容量的限制。
但是，早期Kubernetes版本并没有限制container的rootfs的容量，由于默认容器使用的log存储空间是在 /var/lib/kubelet/ 下，rootfs在/var/lib/docker下，而这两个目录默认就在宿主机Node的根分区，如果应用恶意攻击，可以通过在容器内大量dd从而迅速造成宿主机Node根分区文件系统满。我们知道，当Linux根分区使用达到100%的时候，通常会很危险。
Kubernetes在1.8版本引入了一种新的resource：local ephemeral storage（临时存储），用来管理本地临时存储，对应特性 LocalStorageCapacityIsolation。从1.10开始该特性转为beta状态，默认开启。如果你想和更多 Kubernetes 技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。
临时存储，如emptyDir volumes, container logs，image layers and container writable layers，默认它们使用的是 /var/lib/kubelet，通过限制临时存储容量，也就可以保护Node的root分区了。
本地临时存储管理只对root分区有效，如果你定制了相关的参数，例如 --root-dir，则不会生效。
#配置
我的集群版本是1.14，默认开启了 local ephemeral storage 的特性，只需要配置Pod即可。
Pod的每个container都可以配置：
* spec.containers[].resources.limits.ephemeral-storage
* spec.containers[].resources.requests.ephemeral-storage
单位是byte，可以直接配置，也可以按E/P/T/G/M/K或者Ei, Pi, Ti, Gi, Mi, Ki.为单位来配置，例如 128974848, 129e6, 129M, 123Mi 表示的是同一个容量。
下面创建一个Deployment，设置其使用的临时存储最大为2Gi。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
namespace: default
spec:
selector:
matchLabels:
run: nginx
template:
metadata:
labels:
run: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
limits:
ephemeral-storage: 2Gi
requests:
ephemeral-storage: 2Gi
Pod启动后，进入容器，执行dd if=/dev/zero of=/test bs=4096 count=1024000 ，尝试创建一个4Gi的文件，可以发现在执行一段时间后，Pod被 Evict，controller重新创建了新的Pod。
nginx-75bf8666b8-89xqm 1/1 Running 0 1h
nginx-75bf8666b8-pm687 0/1 Evicted 0 2h
#实现
Evict Pod动作是由kubelet完成的。每个节点上的kubelet会启动一个evict manager，每10秒种(evictionMonitoringPeriod)进行一次检查，ephemeral storage的检查也是在这个阶段完成的。
evict manager可以对pod和container来检查超额应用。
func (m [i]managerImpl) localStorageEviction(summary [/i]statsapi.Summary, pods [][i]v1.Pod) [][/i]v1.Pod {
statsFunc := cachedStatsFunc(summary.Pods)
evicted := []*v1.Pod{}
for _, pod := range pods {
podStats, ok := statsFunc(pod)
if !ok {
continue
}
if m.emptyDirLimitEviction(podStats, pod) {
evicted = append(evicted, pod)
continue
}
if m.podEphemeralStorageLimitEviction(podStats, pod) {
evicted = append(evicted, pod)
continue
}
if m.containerEphemeralStorageLimitEviction(podStats, pod) {
evicted = append(evicted, pod)
}
}
return evicted
}
其中Pod为GetActivePods获取的本节点所有非Terminated状态的Pod。
kubelet会依此检查Pod的emptyDir、Pod级临时存储、container级临时存储，若Pod需要被evict，则加到evicted数组，之后会将evicted的Pod挤出。
contaier级检查比较简单，因为ephemeral storage设置的就是在container上，依次检查container的使用情况和设置的limits，如果超过了limits，则要加入到evicted pods列表中。
相关代码在 containerEphemeralStorageLimitEviction 中。
而Pod级别的检查会复杂一点。
首先是限制值的计算。
kubelet会统计Pod所有container（但不包括init container）的ephemeral storage limits之和。init container指定的是Pod的配额最低需求（有点像最低工资标准，用于生活保障），当所有container指定的配额，超过init container指定的配额时，将忽略init container指定的配额。数学描述如下。
max(sum(containers), initContainer1, initContainer2, ...)
而实际临时存储用量的计算，除了会计算指定过ephemeral storage的container的使用量，还会统计未指定过ephemeral storage的container，以及emptyDir的使用量。
当实际临时存储用量，超过了限制值时，kubelet会将该Pod Evict，然后等待controller重新创建新的Pod并重新调度。
相关代码在 podEphemeralStorageLimitEviction 中。
#requests
注意，设置的local ephemeralstorage requests在evict manager处理过程中没有用到。但是它不是没用的。
创建Pod后，scheduler会将该Pod调度到集群中某个node上。由于每个node所能承载的local ephemeral storage是有上限的，所以scheduler会保证该node上所有Pod的 local ephemeralstorage requests 总和不会超过node的根分区容量。
#inode 保护
有的时候，我们会发现磁盘写入时会报磁盘满，但是df查看容量并没有100%使用，此时可能只是因为inode耗尽造成的。因此，对平台来说，inode的保护也是需要的。
其中，podLocalEphemeralStorageUsage 也统计了container或者pods使用的inode的数量。
但是当前Kubernetes并不支持对Pod的临时存储设置inode的limits/requests。
当然了，如果node进入了inode紧缺的状态，kubelet会将node设置为 under pressure，不再接收新的Pod请求。
#emptyDir
emptyDir也是一种临时存储，因此也需要限制使用。
在Pod级别检查临时存储使用量时，也会将emptyDir的使用量计算在内，因此如果对emptyDir使用过量后，也会导致该Pod被kubelet Evict。
另外，emptyDir本身也可以设置容量上限。如下所摘录编排文件片段，我指定了emptyDir使用内存作为存储介质，这样用户可以获得极好的读写性能，但是由于内存比较珍贵，我只提供了64Mi的空间，当用户在 /cache 目录下使用超过64Mi后，该Pod会被kubelet evict。
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- emptyDir:
medium: Memory
sizeLimit: 64Mi
name: cache-volume
相关代码在 emptyDirLimitEviction 中。
原文链接：https://ieevee.com/tech/2019/05/23/ephemeral-storage.html
