回滚

工作 流程引擎回滚的应用背景： 场景1：一件流程在完成后，发现这个流程有问题，需要 退回 到流程指定的节点上与当时该节点的处理人身上，让他重做。 场景2：一个主流程启动了n个子流程，他在监控子流程时发现子流程问题，需要重新去做。 这两种场景下，都是在流程完全处理完后，并且流程引擎已经把该流程归档后要求重新回滚到指定的节点与该节点的处理人身上去，让其在重新去处理。 ccflow 工作流程引擎回滚流程对应的API： /// <summary> /// 恢复已完成的流程数据到指定的节点，如果节点为0就恢复到最后一个完成的节点上去. /// 恢复失败抛出异常 /// </summary> /// <param name="flowNo">要恢复的流程编号</param> /// <param name="workid">要恢复的workid</param> /// <param name="backToNodeID">恢复到的节点编号，如果是0，标示回复到流程最后一个节点上去.</param> /// <param name="note">恢复的原因，此原因会记录到日志</param> public static string Flow_DoRebackWorkFlow(string flowNo, Int64 workid, int backToNodeID, string note)

记性不太好经常忘记命令，整理一下方便翻阅。 查看git设置 git config --list 设置git用户 git config --global user.name="Your Name" git config --global user.email="Your Email" 初始化git git init 一般情况下还需要创建一个.gitignore文件设置忽略提交的文件，提交空文件夹需要在文件夹内添加.gitkeep文件 撤销git初始化 rm -rf .git 查看git项目状态 git status 添加项目/文件到暂存区 git add . 或 git add -A git add 1.txt 取消提交到暂存区 git rm --cached . -r 提交到版本库 git commit -m 'Commit Message' 快捷提交到版本库（提交的内容必须已经提交过一次） git commit -a -m "Commit Message" 查看提交日志 git log git log --graph //图谱模式 git log --graph --oneline //精简图谱模式 比较差异 git diff //默认工作区和暂存区对比 git diff master //工作区和版本库区对比 git diff --cached //暂存区和版本库区对比

需求 老大：zain啊，咱们的数据库今天有多少查询语句啊？ 我 ：额，稍等，我看看啊； 心想，{尼玛，我怎么知道有多少select语句啊} 那么问题来了，如何查看MySQL数据库的生产服务器有多少的查询语句那？这里使用到了show global status like 命令来查询，同时写了一个简单的脚本，每天定时00.00执行，然后发送到管理员邮箱来实现sql语句的执行状态记录； 通过 show global status; 可以列出MySQL服务器运行sql语句的各种状态值，我个人较喜欢的用法是show global status like '查询值%'; 来查询某个值，下面就说一下我们线上都做了那些值得记录， 注意哦：要在并发量不大的情况下操作，在slave服务器上执行查询语句，如果在线上并发量很大的情况下操作，出现问题自己负责，这里已经做了说明，下面就开开始实操演练； mysql> show global status; #此次在内部测试服务器操作 +-----------------------------------------------+---------------------+ | Variable_name | Value | +-----------------------------------------------+-------------------

应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。 长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、灰度发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。 7.1 蓝绿发布 项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。 当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。 最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。 特点 如果出问题，影响范围较大； 发布策略简单； 用户无感知，平滑过渡； 升级/回滚速度快。 缺点 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发； 短时间内浪费一定资源成本； 基础设施无改动，增大升级稳定性。 蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。 7.2 灰度发布 灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。 特点 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控； 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小

基本概念: Swarm介绍： Swarm是Docker公司在2014年12月初发布的一套较为简单的工具，用来管理Docker集群，它将一群Docker宿主机变成一个单一的虚拟的主机。 Swarm使用标准的Docker API接口作为其前端访问入口，换言之，各种形式的Docker Client(dockerclient in Go, docker_py,docker等)均可以直接与Swarm通信。Swarm几乎全部用Go语言来完成开发，Swarm0.2版本增加了一个新的策略来调度集群中的容器，使得在可用的节点上传播它们，以及支持更多的Docker命令以及集群驱动。Swarm deamon只是一个调度器（Scheduler）加路由器(router)，Swarm自己不运行容器，它只是接受docker客户端发送过来的请求，调度适合的节点来运行容器，这意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，当Swarm重新恢复运行之后，它会收集重建集群信息。 docker客户端发送过来的请求，调度适合的节点来运行容器，这意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，当Swarm重新恢复运行之后，它会收集重建集群信息。 Swarm集群的特性： 集群中可以都是manager，但不可以都是worker。 Node：节点. manager:经理，管理者 worker