Golang实现云原生数据库代理 分库分表中间件开发

直接去干的。

核心模块应该是：
SQL解析器是现成的。
vitess配置的解析器简单易用，不需要重新发明轮子。
解析 SQL 并将其转换为 AST，以提取表名和条件，以便路由引擎可以使用它们。

路由引擎分为几类。


范围路由：基于 ID 范围的分片（例如分片 A 的 ID1 到 1 000）。

哈希路由：hash(key)%N，保证均匀分布。

一致性哈希：Ketama算法，减少节点增删改迁。

自定义路由：您可以根据需要定义规则。

事务一致性是关键。
不要在跨分片交易上强制使用 2 PC。
使用Saga协议比2 PC要好。

连接池管理：

使用数据库/SQL就足够了。

每个分片都有独立的连接池，防止泄露。

应该清楚地了解最大连接数和空闲超时。

合并结果：

SELECT 需要合并行，并且必须处理排序和分页。

COUNT/SUM 直接累加每个分片的结果。

JOIN 不应尽可能跨分片。
数据冗余是您最好的选择。

云原生功能集成：
Docker镜像打包、K8 s部署。

K8 sService 用于服务发现并知道分片节点何时移动。

灵活的扩展取决于负载、CPU/内存或自定义指标。

使用ConfigMap进行配置，并将密码放入Secret中。

我们使用Prometheus+Grafana进行监控。
所有指标全部暴露，警报全部清除。

性能优化：

快速做出路由决策并缓存结果。

结果是异步合并的，因此它们不会卡在主线程上。

事务使用最终一致性，Saga优于2 PC。

数据一致性：

日志统计采用消息队列异步同步。

短期交易使用2 PC，长期交易使用Saga。

需要乐观锁定和数据验证。

运维发布：
灰度发布：初期释放1 0%的流量，稳定后再添加。

完全迁移：关机期间导入数据。

增量迁移：双写+pt-table-checksum验证。

切换过程：调整数据后修改路由规则。

Golang的优点：
Goroutines轻量级、高并发、廉价。

GC垃圾回收，性能波动小。

丰富的生态库：vites/sqlparser、go-sql-driver/mysql 都很有用。

总体架构：
客户端 → Ingress → Agent集群 → 分片数据库集群。

代理集群是无状态的，由 K8 s 管理。

分片数据库主从，独立部署。

Prometheus 中暴露了用于监控的 /metrics 接口。

这样分库分表、数据一致性、云原生特性都考虑到了。
性能、扩展性、运维都可靠。

基于云计算的医院临床信息系统，java版云HIS源代码

说白了，云版HIS Java的核心有两点：稳定的架构选型和精准的功能实现。
由于医学领域的特殊性，这个问题很复杂，但只要采用正确的技术，这个问题就很简单。

我们先来说说最重要的架构的选择。
基础是纯三层B/S架构。
去年我们跑的3 000级的项目，纯前端其实是没有问题的，但是如果使用混合模式的话，客户端维护成本会直接翻倍。
还有一点就是微服务的划分不能太死板。
预约登记等高频模块必须独立。
但对于病历管理等相关性强的数据，拆分成微服务会带来通信延迟问题。
我一开始以为辅助数据库可以解决问题，但后来发现这是错误的。
这也取决于公司的时间安排。
还有另一个关键细节。
在支持多租户时，数据库分片的性能比Schema好，但扩展性较差，必须根据医院的规模来评估。

等一下，还有一件事。
技术选择不能仅仅基于时尚。
SpringBoot速度很快，但通过MyBatis和Redis缓存，我们测量它可以承受平均每天1 0万个呼叫的门诊系统。
接口规格直接采用HL7 FHIR标准连接LIS/PACS系统。
虽然初期开发量相当大，但以后连接新设备时节省了9 0%的工作量。

说实话，这很令人困惑。
选择阿里云还是腾讯云作为实施方案取决于您当地的医保接口。
去年我们因为没有提前了解结算系统的兼容性而感到沮丧。
初期建议使用K8 进行容器部署。
虽然学习曲线陡峭，但是后期弹性伸缩确实不错。

最后提醒：不要使用太复杂的 EHR 模板引擎。
百里香叶就够了。
添加高级模板会减慢医生记录病历的速度。

Carina 的根基与诞生背景｜深入了解 Carina 系列 第一期

上周我告诉过你关于卡琳娜的事。
这个项目很有趣。

2 02 3 年 1 0 月，Carina 刚刚开源。
但2 02 0年就已经开始了。

博云的朋友说Carina的心是CSI。
确实，CSI是关键。

在CSI之前，更新存储插件太复杂。
云提供商代码必须随 Kubernetes 一起更改。
这肯定行不通。

Carina解决了本地存储问题。
中间件可以迁移到云端，但不能迁移到网络存储。
想想具有高 IOPS 要求和低延迟的数据库。

因此Carina的目标非常明确。
本地性能高，无需运维。

具体功能包括创建卷和挂载卷。
该架构分为三部分：控制器、节点和调度器。

节点负责管理本地磁盘。
自动创建卷组并将其注册到 Kubernetes。

流程如下：用户创建 PVC，控制器要求 N​​ode 创建卷，Kubernetes 挂载它。

2 02 0年上线，2 02 1 年开源。
迭代速度相当快。

一开始想做一个简单的部署，现在功能很多了。
有缓存和速度限制。

算了，这取决于你。