给前端使用的服务接口,一般采用JSON或GraphQL格式。微服务间的服务接口,一般采用JSON或gRPC格式。
Gin是一个非常流行的HTTP服务框架,在GitHub上的Stars已有32k。在提供JSON或GraphQL格式的服务接口时,Gin是一个非常明智的选择。在提供gRPC格式的服务接口时,使用官方的工具protoc-gen-go
自动生成代码也比较便捷。
格式 |
优点 |
缺点 |
选择时考虑点 |
JSON |
最通用;数据自描述 |
数组时冗余数据大;序列化效率不高 |
不需要schema,能自动识别属性与数据;JSON序列化不是性能问题点 |
GraphQL |
一次请求获取所需的、最少的所有数据;自带输入数据校验 |
本身也是JSON格式,且更高层次的封装,性能比单纯的JSON略差 |
前端使用,想提高网络访问性能;服务聚合 |
gRPC |
高效的序列化,字节流最小 |
需要schema才能解析数据的含义;不通用 |
使用JSON格式时,网络传输与序列化出现性能问题时,就该换到gRPC |
继续阅读→
在分布式系统中考虑7x24h不间断服务时,相比无状态的应用服务,有状态的数据存储服务是一个非常重要又比较麻烦的部分。
在云原生中,无状态服务与有状态服务的区别有:
事件 |
无状态服务 |
有状态服务 |
升级 |
直接部署新版本,删/减老版本实例 |
升级Schema; 新增表,双表操作,到下个版本才能完全迁移 |
POD异常 |
拉起新的POD实例 |
选举副本做Master,再拉起新的副本实例;在客户端中熔断,写操作切换到新的Master |
负载均衡 |
Service Mesh或IPVS负载均衡,非侵入式 |
分片选择:SQL协议Proxy模式;客户端侵入式 |
数据库的升级/维护,选择GitOps比较合适,避免人工直接操作环境。
本文中,我们不演示如何实现高可用、高并发的数据库集群的Master选举、客户端熔断,只演示:
- 如何连接数据库单例或集群
- 如何完成增、删、改、查等基本操作
继续阅读→
在分布式微服务系统中,Kafka一般用于事件溯源(Event Sourcing)的存储与异步消息队列。Redis一般用于数据缓存,提升系统的吞吐量,减少持久层的压力。后端落地CQRS模式(Command-Query Responsibility Segregation )时,带上它们俩可以事半功倍。
继续阅读→