实测现阶段BUG还比较多，用于生产还有些难度。但是作为国内的开源项目，算是不错的了，毕竟国内的开源环境并不好。如果你自己有一定技术实力可以考虑参与这个项目的维护，
专注于为中小企业提供成都网站建设、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业会泽免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000+企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
补充一点，这是个工作流引擎，权限管理只是它的一个基础功能，使用的是比较常见的G/RBAC的体系架构，如果是只使用权限管理，肯定还有其他的选择。
在 Kubernetes 的监控方案中我们经常会使用到一个Promethues Operator的项目，该项目可以让我们更加方便的去使用 Prometheus，而不需要直接去使用最原始的一些资源对象，比如 Pod、Deployment，随着 Prometheus Operator 项目的成功，CoreOS 公司开源了一个比较厉害的工具：Operator Framework，该工具可以让开发人员更加容易的开发 Operator 应用。
在本篇文章中我们会为大家介绍一个简单示例来演示如何使用 Operator Framework 框架来开发一个 Operator 应用。
Kubernetes Operator
Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建Operator 的关键是CRD（自定义资源）的设计。
Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。
Operator Framework
Operator Framework 同样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：
Workflow
Operator SDK 提供以下工作流来开发一个新的 Operator：
Demo
我们平时在部署一个简单的 Webserver 到 Kubernetes 集群中的时候，都需要先编写一个 Deployment 的控制器，然后创建一个 Service 对象，通过 Pod 的 label 标签进行关联，最后通过 Ingress 或者 type=NodePort 类型的 Service 来暴露服务，每次都需要这样操作，是不是略显麻烦，我们就可以创建一个自定义的资源对象，通过我们的 CRD 来描述我们要部署的应用信息，比如镜像、服务端口、环境变量等等，然后创建我们的自定义类型的资源对象的时候，通过控制器去创建对应的 Deployment 和 Service，是不是就方便很多了，相当于我们用一个资源清单去描述了 Deployment 和 Service 要做的两件事情。
这里我们将创建一个名为 AppService 的 CRD 资源对象，然后定义如下的资源清单进行应用部署：
通过这里的自定义的 AppService 资源对象去创建副本数为2的 Pod，然后通过 nodePort=30002 的端口去暴露服务，接下来我们就来一步一步的实现我们这里的这个简单的 Operator 应用。
开发环境
环境需求
要开发 Operator 自然 Kubernetes 集群是少不了的，还需要 Golang 的环境，这里的安装就不多说了，然后还需要一个 Go 语言的依赖管理工具包：dep，由于 Operator SDK 是使用的 dep 该工具包，所以需要我们提前安装好，可以查看资料：，另外一个需要说明的是，由于 dep 去安装的时候需要去谷歌的网站拉取很多代码，所以正常情况下的话是会失败的，需要做什么工作大家应该清楚吧？要科学。
安装 operator-sdk
operator sdk 安装方法非常多，我们可以直接在 github 上面下载需要使用的版本，然后放置到 PATH 环境下面即可，当然也可以将源码 clone 到本地手动编译安装即可，如果你是 Mac，当然还可以使用常用的 brew 工具进行安装：
我们这里使用的 sdk 版本是v0.7.0，其他安装方法可以参考文档：
演示
创建新项目
环境准备好了，接下来就可以使用 operator-sdk 直接创建一个新的项目了，命令格式为： operator-sdk new
按照上面我们预先定义的 CRD 资源清单，我们这里可以这样创建：
到这里一个全新的 Operator 项目就新建完成了。
项目结构
使用operator-sdk new命令创建新的 Operator 项目后，项目目录就包含了很多生成的文件夹和文件。
我们主要需要编写的是 pkg 目录下面的 api 定义以及对应的 controller 实现。
添加 API
接下来为我们的自定义资源添加一个新的 API，按照上面我们预定义的资源清单文件，在 Operator 相关根目录下面执行如下命令：
添加完成后，我们可以看到类似于下面的这样项目结构：
添加控制器
上面我们添加自定义的 API，接下来可以添加对应的自定义 API 的具体实现 Controller，同样在项目根目录下面执行如下命令：
这样整个 Operator 项目的脚手架就已经搭建完成了，接下来就是具体的实现了。
自定义 API
打开源文件pkg/apis/app/v1/appservice_types.go，需要我们根据我们的需求去自定义结构体 AppServiceSpec，我们最上面预定义的资源清单中就有 size、image、ports 这些属性，所有我们需要用到的属性都需要在这个结构体中进行定义：
代码中会涉及到一些包名的导入，由于包名较多，所以我们会使用一些别名进行区分，主要的包含下面几个：
这里的 resources、envs、ports 的定义都是直接引用的"k8s.io/api/core/v1"中定义的结构体，而且需要注意的是我们这里使用的是ServicePort，而不是像传统的 Pod 中定义的 ContanerPort，这是因为我们的资源清单中不仅要描述容器的 Port，还要描述 Service 的 Port。
然后一个比较重要的结构体AppServiceStatus用来描述资源的状态，当然我们可以根据需要去自定义状态的描述，我这里就偷懒直接使用 Deployment 的状态了：
定义完成后，在项目根目录下面执行如下命令：
改命令是用来根据我们自定义的 API 描述来自动生成一些代码，目录pkg/apis/app/v1/下面以zz_generated开头的文件就是自动生成的代码，里面的内容并不需要我们去手动编写。
实现业务逻辑
NewDeploy 方法实现如下：
newService 对应的方法实现如下：
这样我们就实现了 AppService 这种资源对象的业务逻辑。
调试
如果我们本地有一个可以访问的 Kubernetes 集群，我们也可以直接进行调试，在本地用户~/.kube/config文件中配置集群访问信息，下面的信息表明可以访问 Kubernetes 集群：
首先，在集群中安装 CRD 对象：
上面的命令会在本地运行 Operator 应用，通过~/.kube/config去关联集群信息，现在我们去添加一个 AppService 类型的资源然后观察本地 Operator 的变化情况，资源清单文件就是我们上面预定义的（deploy/crds/app_v1_appservice_cr.yaml）
直接创建这个资源对象：
我们可以看到我们的应用创建成功了，这个时候查看 Operator 的调试窗口会有如下的信息出现：
然后我们可以去查看集群中是否有符合我们预期的资源出现：
看到了吧，我们定义了两个副本（size=2），这里就出现了两个 Pod，还有一个 NodePort=30002 的 Service 对象，我们可以通过该端口去访问下应用：
如果应用在安装过程中出现了任何问题，我们都可以通过本地的 Operator 调试窗口找到有用的信息，然后调试修改即可。
清理：
部署
自定义的资源对象现在测试通过了，但是如果我们将本地的operator-sdk up local命令终止掉，我们可以猜想到就没办法处理 AppService 资源对象的一些操作了，所以我们需要将我们的业务逻辑实现部署到集群中去。
执行下面的命令构建 Operator 应用打包成 Docker 镜像：
镜像构建成功后，推送到 docker hub：
镜像推送成功后，使用上面的镜像地址更新 Operator 的资源清单：
现在 Operator 的资源清单文件准备好了，然后创建对应的 RBAC 的对象：
到这里我们的 CRD 和 Operator 实现都已经安装成功了。
现在我们再来部署我们的 AppService 资源清单文件，现在的业务逻辑就会在上面的opdemo-64db96d575-9vtq6的 Pod 中去处理了。
然后同样的可以通过 30002 这个 NodePort 端口去访问应用，到这里应用就部署成功了。
清理
有资源清单文件，直接删除即可：
开发
Operator SDK 为我们创建了一个快速启动的代码和相关配置，如果我们要开始处理相关的逻辑，我们可以在项目中搜索TODO(user)这个注释来实现我们自己的逻辑，比如在我的 VSCode 环境中，看上去是这样的：
本篇文章示例代码地址：
参考资料
TiDB 是 PingCAP 自主研发的开源分布式关系型数据库，具备商业级数据库的数据可靠性，可用性，安全性等特性，支持在线弹性水平扩展，兼容 MySQL 协议及生态，创新性实现 OLTP 及 OLAP 融合。
TiDB 3.0 版本显著提升了大规模集群的稳定性，集群支持 150+ 存储节点，300+TB 存储容量长期稳定运行。易用性方面引入大量降低用户运维成本的优化，包括引入 Information_Schema 中的多个实用系统视图、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特别是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升约 4.5 倍，Sysbench 性能提升约 1.5 倍，OLAP 方面，TPC-H 50G Q15 因实现 View 可以执行，至此 TPC-H 22 个 Query 均可正常运行。新功能方面增加了窗口函数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）。
截止本文发稿时 TiDB 已在 500+ 用户的生产环境中长期稳定运行，涵盖金融、保险、制造，互联网， 游戏 等领域，涉及交易、数据中台、 历史 库等多个业务场景。不同业务场景对关系型数据库的诉求可用 “百花齐放”来形容，但对关系数据库最根本的诉求未发生任何变化，如数据可靠性，系统稳定性，可扩展性，安全性，易用性等。请跟随我们的脚步梳理 TiDB 3.0 有什么样的惊喜。
3.0 与 2.1 版本相比，显著提升了大规模集群的稳定性，支持单集群 150+ 存储节点，300+TB 存储容量长期稳定运行，主要的优化点如下：
1. 优化 Raft 副本之间的心跳机制，按照 Region 的活跃程度调整心跳频率，减小冷数据对集群的负担。
2. 热点调度策略支持更多参数配置，采用更高优先级，并提升热点调度的准确性。
3. 优化 PD 调度流程，提供调度限流机制，提升系统稳定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 时间，提升系统稳定性。
众所周知，数据库查询计划的稳定性对业务至关重要，TiDB 3.0 版本采用多种优化手段提升查询计划的稳定性，如下：
1. 新增 Fast Analyze 功能，提升收集统计信息的速度，降低集群资源的消耗及对业务的影响。
2. 新增 Incremental Analyze 功能，提升收集单调递增的索引统计信息的速度，降低集群资源的消耗及对业务的影响。
3. 在 CM-Sketch 中新增 TopN 的统计信息，缓解 CM-Sketch 哈希冲突导致估算偏大，提升代价估算的准确性，提升查询计划的稳定性。
4. 引入 Skyline Pruning 框架，利用规则防止查询计划过度依赖统计信息，缓解因统计信息滞后导致选择的查询计划不是最优的情况，提升查询计划的稳定性。
5. 新增 SQL Plan Management 功能，支持在查询计划不准确时手动绑定查询计划，提升查询计划的稳定性。
1. OLTP
3.0 与 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升约 1.5 倍，TPC-C 性能提升约 4.5 倍。主要的优化点如下：
1. TiDB 持续优化 SQL 执行器，包括：优化 NOT EXISTS 子查询转化为 Anti Semi Join，优化多表 Join 时 Join 顺序选择等。
2. 优化 Index Join 逻辑，扩大 Index Join 算子的适用场景并提升代价估算的准确性。
3. TiKV 批量接收和发送消息功能，提升写入密集的场景的 TPS 约 7%，读密集的场景提升约 30%。
4. TiKV 优化内存管理，减少 Iterator Key Bound Option 的内存分配和拷贝，多个 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存储引擎插件，提升 Value 值超过 1KB 时性能，缓解 RocksDB 写放大问题，减少磁盘 IO 的占用。
6. TiKV 新增多线程 Raftstore 和 Apply 功能，提升单节点内可扩展性，进而提升单节点内并发处理能力和资源利用率，降低延时，大幅提升集群写入能力。
TiDB Lightning 性能与 2019 年年初相比提升 3 倍，从 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，优化点，如下：
1. 提升 SQL 转化成 KV Pairs 的性能，减少不必要的开销。
2. 提升单表导入性能，单表支持批量导入。
3. 提升 TiKV-Importer 导入数据性能，支持将数据和索引分别导入。
4. TiKV-Importer 支持上传 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的权限访问控制） 是商业系统中最常见的权限管理技术之一，通过 RBAC 思想可以构建最简单“用户-角色-权限”的访问权限控制模型。RBAC 中用户与角色关联，权限与角色关联，角色与权限之间一般是多对多的关系，用户通过成为什么样的角色获取该角色所拥有的权限，达到简化权限管理的目的，通过此版本的迭代 RBAC 功能开发完成。
IP 白名单功能（企业版特性） ：TiDB 提供基于 IP 白名单实现网络安全访问控制，用户可根据实际情况配置相关的访问策略。
Audit log 功能（企业版特性） ：Audit log 记录用户对数据库所执行的操作，通过记录 Audit log 用户可以对数据库进行故障分析，行为分析，安全审计等，帮助用户获取数据执行情况。
加密存储（企业版特性） ：TiDB 利用 RocksDB 自身加密功能，实现加密存储的功能，保证所有写入到磁盘的数据都经过加密，降低数据泄露的风险。
完善权限语句的权限检查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 语句权限检查。
1. 新增 SQL 方式查询慢查询，丰富 TiDB 慢查询日志内容，如：Coprocessor 任务数，平均/最长/90% 执行/等待时间，执行/等待时间最长的 TiKV 地址，简化慢查询定位工作，提高排查慢查询问题效率，提升产品易用性。
2. 新增系统配置项合法性检查，优化系统监控项等，提升产品易用性。
3. 新增对 TableReader、IndexReader 和 IndexLookupReader 算子内存使用情况统计信息，提高 Query 内存使用统计的准确性，提升处理内存消耗较大语句的效率。
4. 制定日志规范，重构日志系统，统一日志格式，方便用户理解日志内容，有助于通过工具对日志进行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 调优的易用性。
6. 新增 SQL 语句 Trace 功能，方便排查问题。
7. 新增通过 unix_socket 方式连接数据库。
8. 新增快速恢复被删除表功能，当误删除数据时可通过此功能快速恢复数据。
TiDB 3.0 新增 TiFlash 组件，解决复杂分析及 HTAP 场景。TiFlash 是列式存储系统，与行存储系统实时同步，具备低延时，高性能，事务一致性读等特性。 通过 Raft 协议从 TiKV 中实时同步行存数据并转化成列存储格式持久化到一组独立的节点，解决行列混合存储以及资源隔离性问题。TiFlash 可用作行存储系统（TiKV）实时镜像，实时镜像可独立于行存储系统，将行存储及列存储从物理隔离开，提供完善的资源隔离方案，HTAP 场景最优推荐方案；亦可用作行存储表的索引，配合行存储对外提供智能的 OLAP 服务，提升约 10 倍复杂的混合查询的性能。
TiFlash 目前处于 Beta 阶段，计划 2019 年 12 月 31 日之前 GA，欢迎大家申请试用。
未来我们会继续投入到系统稳定性，易用性，性能，弹性扩展方面，向用户提供极致的弹性伸缩能力，极致的性能体验，极致的用户体验。
稳定性方面 V4.0 版本将继续完善 V3.0 未 GA 的重大特性，例如：悲观事务模型，View，Table Partition，Titan 行存储引擎，TiFlash 列存储引擎；引入近似物理备份恢复解决分布数据库备份恢复难题；优化 PD 调度功能等。
性能方面 V4.0 版本将继续优化事务处理流程，减少事务资源消耗，提升性能，例如：1PC，省去获取 commit ts 操作等。
弹性扩展方面，PD 将提供弹性扩展所需的元信息供外部系统调用，外部系统可根据元信息及负载情况动态伸缩集群规模，达成节省成本的目标。
我们相信战胜“未知”最好的武器就是社区的力量，基础软件需要坚定地走开源路线。截止发稿我们已经完成 41 篇源码阅读文章。TiDB 开源社区总计 265 位 Contributor，6 位 Committer，在这里我们对社区贡献者表示由衷的感谢，希望更多志同道合的人能加入进来，也希望大家在 TiDB 这个开源社区能够有所收获。
TiDB 3.0 GA Release Notes：
前后端分离是现在主流的架构设计模式，它初衷是用「单一职责」原则把代码质量提上去从而达到节省人力和减少沟通时的信息损失的目的。
本文推荐九个前后端分离的开源项目，都是采用最流行的技术栈。本文推荐的开源项目已经收录到 Awesome GitHub Repo。
Awesome GitHub Repo 是逛逛 GitHub 创建的开源项目，会收集整理 GitHub 上高质量、有趣的开源项目，并将他们进行归类。
该开源项目集不是简单的按照编程语言来分类，而是按照更有趣的分类方式，比如：有趣项目、沙雕项目、实战项目、学习项目、实用工具等等。
本期推荐的开源项目是：
1. 前后端分离博客系统
2. 前后端分离考试系统
3. 基于 TypeScript 的聊天室项目
4. 人力资源管理开源项目
5. 一个可以用来练手的前后端分离项目
6. 学之思开源考试系统
7. 前后端分离的后台管理系统
8. 前后端管理平台一站式脚手架
9. 一个系列项目：NiceFish（美人鱼）
01 前后端分离博客系统
这是一款基于 Spring Boot = Vue 的前后端分离的博客系统，后端采用技术栈：Spring Boot、Spring Security、jjwt、MyBatis、PageHelper、Redis、commonmark-java、ip2region、quartz、yauaa。
前端核心框架：Vue2.x、Vue Router、Vuex；Vue 项目基于 @vue/cli4.x 构建。JS 依赖及参考的 CSS：axios、moment、nprogress、v-viewer、prismjs、APlayer、MetingJS、lodash、mavonEditor、echarts、tocbot、iCSS
02 前后端分离考试系统
该项目是一个前后端分离的在线考试系统。后端使用 Spring Boot，前端使用 VUE 和 Element-UI 组件库配合完成开发。
03 基于 TypeScript 的聊天室项目
该项目是一个聊天室，采用全 TypeScript 开发，目前聊天室已经具备完整的聊天功能，有兴趣的朋友可以自行 fork 去开发。
技术选型：Typescript、Vue2.6.x、Socket/io、Vuex、Nestjs、Typeorm、ES6+、SASS(SCSS)。
04 人力资源管理系统
微人事是一个前后端分离的人力资源管理系统，项目采用 Spring Boot + Vue 开发。首先，不同的用户在登录成功之后，根据不同的角色，会看到不同的系统菜单，完整菜单如下：
每个用户的角色是由系统管理员进行分配的，系统管理员给用户分配角色的页面如下：
系统管理员也可以管理不同角色可以操作的资源，页面如下：
后端技术栈：Spring Boot、Spring Security、MyBatis、MySQL、Redis、RabbitMQ、Spring Cache、WebSocket
前端技术栈：Vue、ElementUI、axios、vue-router、Vuex、WebSocket、vue-cli4
05 前后端分离练手项目
一个基于 Spring Boot + Vue 开发的前后端分离博客项目，带有超级详细开发文档和讲解视频。还未接触过 Vue 开发或者前后端分离的同学可以学起来。
06 开源考试系统
学之思开源考试系统是一款 Java + Vue 的前后端分离的考试系统。主要优点是开发、部署简单快捷、界面设计友好、代码结构清晰。
支持 Web 端和微信小程序，能覆盖到 PC 机和手机等设备。支持多种部署方式：集成部署、前后端分离部署、Docker 部署。
07 后台管理系统
一个基于 Spring Boot 2.1.0 、 Spring Boot Jpa、 JWT、Spring Security、Redis、Vue 的前后端分离的后台管理系统。
项目采用分模块开发方式， 权限控制采用 RBAC，支持数据字典与数据权限管理，支持一键生成前后端代码，支持动态路由。
体验地址：
账号密码：admin / 123456
08 前后端管理平台一站式脚手架
本项目基于Spring Cloud 和Ant Design Pro实现前后端管理平台一站式脚手架，便于快速开发企业级应用。我们的愿景是 基于CopyPaste技术，实现面向GoogleBaidu编程，让码农搬砖不累，做更好的良民。
预览地址：；用户名和密码：admin
浏览器输入 localhost:8000 后会自动跳转到登录页
输入用户名和密码 admin/admin后,跳转到首页
Cookie中JWT Token
监控服务 localhost:8001效果(如果启动了monitor服务，用户名和密码为admin/admin)
移动端效果
09 美人鱼
NiceFish（美人鱼） 是一个系列项目，目标是示范前后端分离的开发模式：前端浏览器、移动端、Electron 环境中的各种开发模式；后端有两个版本：SpringBoot 版本和 SpringCloud 版本。
历史 推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：
重庆分公司
重庆分公司
