个人博客，记录软件技术与程序员的点点滴滴。
在互联网大数据时代，海量数据的存储只能数据分片与分布式存储，在数据处理时又需读写分离、结果归并到应用服务节点。在云原生与微服务中，以下几种数据库均占有自己的一席之地，没有谁可以代替谁：
在微服务系统中，数据架构经历了以下几个过程：
普通DNS协议不支持加密传输，DNS查询时可以被网络中的其它服务伪造数据包响应，查询到的域名IP地址是伪造的，称为“DNS污染”。
为了避免“DNS污染”，有这几种方案：DNSSEC、DNSCrypt、DNS-over-TLS (DoT)、DNS-over-HTTPS (DoH)。除了DNSSEC，其余三种协议都可以避免中间人窃听，是比较安全的传输协议。
DNS加密网络如下：
刚开始参加工作时，时不时跟大家一起打羽毛球，但是现在羽毛球拍放着手胶都老化了。😃
当程序员，经常久坐，有时喝咖啡提神，有时喝碳酸饮料或吃糖缓解压力。工作久了，缺乏运动，又没有控制饮食，长胖了。😆
看到别人玩轮滑，也学着玩，只敢穿带刹车的鞋子上马路，花样轮滑还没有学会，菜鸟水平。那段时间，轮滑是上下班的交通工具，周末经常出去滑个大半天，体重从145斤降到126斤。👍
继续阅读→格雷迪说过：“所有的架构都是设计，但并非所有的设计都是架构”。
软件设计，可以提升代码的可阅读性、可维护性、可扩展性等；一个设计点对软件整体影响比较小，发生变更时代价比较小。避免过度设计，避免无设计，需要找到平衡点才能提升团队的生产效率。本文只关注编码上面的软件设计，不涉及需求分析等其它内容。
软件架构，可以提升系统的可用性、稳定性、高性能等，一个架构点可能影响到整个软件的结构、依赖关系、部署形态等，发生变更时代价往往是巨大的。即使在敏捷组织中，架构点往往需要在相关编码之前确定，编码过程中只进行微调——流程上与软件设计有比较大的差别。
本文中推荐一些软件设计与架构相关的书籍。我先接触到敏捷软件开发思想，所以，从设计模式到软件架构的很多书籍都跟敏捷宣言大佬有关。
在高性能Web服务领域，GoLang使用广泛，不需要依赖第三方库就可以开发出一个Web服务，比C++方便许多。GoLang是一个拥有垃圾回收机制与闭包的静态Native语言。
GoLang拥有良好的软件生态，社区代码一般都共享到GitHub中，代码中可以直接导入Git仓库的第三方模块。从第三方模块管理、代码格式化、静态检查、构建、单元测试到性能测试等，都包含在GoLang官方工具包中，人们很容易编写出符合软件工程规范的代码。在云时代，GoLang拥有良好的前景。
在Web端、移动端、部分桌面客户端，很多用户界面都是HTML/CSS/JavaScript实现的。在性能要求不是特别高的场景，使用前端技术可以提高生产效率，让公司能够抢占先机、创造更大的价值。近10年来，前端技术一直在突飞猛进地发展，各种框架、库、设计理念层出不穷。
HTML/CSS是基础材料，JavaScript/TypeScript才是前端生动的灵魂。前端也能使用到设计模式、架构模式等高级设计理念，如单例模式、工厂模式、观察者模式、事件溯源、CQRS、BFF、MVC/MVVM等。最后，还需要学习前端工程化，静态检查、资源合并/压缩/混淆、资源缓存策略等。可以说，前端有一套独特的、完整的软件体系。
在掌握的几个编程语言中，C++是我花费学习时间最多的编译语言。但是，掌握了C++，再去学习Java、C++等面向对象语言，都非常容易上手，几乎只需关注不同点。
C++是一门最复杂的高级编程语言，说要精通C++，如果不疯狂学习与使用，一切都是妄想。在学习C++的路上，不知道多少人在途中退缩了。从工程的角度，在项目开始时，如果有其它的编程语言满足需求，就不应该选择C++。在项目中，需要综合考虑人员技能、人员替换、程序信息反馈等因素。在高性能应用领域上，如游戏、计算机视觉、高体验客户端、低功耗物联网(IoT)等，C++仍是无可代替的。
给前端使用的服务接口，一般采用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 ）时，带上它们俩可以事半功倍。
继续阅读→