质量保证梳理对于一些需求的实现，使用checklist的方式，回答清楚每一个跟质量相关的问题，帮助开发人员梳理清楚对于质量保证而言最重要的事是什么，做到质量保证“能落地”。 问题列表：如何保证质量？首先得定义质量，要能对质量进行衡量 对于一个软件项目而言，质量意味着什么 可扩展性 以当前的资源部署下，在业务上，能支撑多少业务量 (tps/qps)？ 最早遇到性能瓶颈的模块是什么 ？ 最简单能解决该性能瓶颈的方 2023-03-05 质量保证 qa quality 项目工程 质量
关于质量保证的探讨什么是质量？系统质量，首先保证系统的正常运行，包括功能正确、系统稳定性。其次，要保证系统的健壮性，包括系统的容错能力、报警能力、自恢复能力。还要保证系统的可维护性和可扩展性，包括系统功能增加/修改的难易程度、系统横向扩展的能力。 我们主要关注哪些点？ 保证正确的业务逻辑 任意一个功能都是符合业务预期的，覆盖业务所需要的所有场景。 保证可维护性 考虑功能规划，确保在之后的新业务需求开发时， 2023-03-05 质量保证 qa quality 项目工程 质量
服务化演进的一些问题探讨前两天在 go-krotas 的微信群里，看到一哥们儿提问: 在 k8s 中，不理解为啥还需要 registry ? 直接用 service 不就行了吗？ 我回答道: 我觉得直接用 service 主要的问题是 扩展性问题。业务上会有各种对服务分组的需求，比如版本、地域等等。 但是四层的负载均衡比较难做到。所以基于注册中心 + subset 的方式就有了生存空间。不过，如果是比较简单的场景 2023-03-05 devops 云原生 微服务 istio 服务治理 反微服务 microservice
serverless_究竟是何方神圣？什么是 serverless顾名思义，serverless 就是 server-less，也就是 别话时间去搞服务器 => 把精力全都放到业务开发上 ! 在传统的开发流程中，一个团队的标准配置是： 前端工程师 * x + 后端工程师 * y + 运维工程师 * z 。 前端写交互，后端写数据逻辑与存储，运维就搞服务部署、灰度、日志、监控等等。每个岗位各司其职，看起来十分完美。 但有时候也没有 2023-03-05 k8s serverless faas baas cloud native
如何做好压测压测的目标是什么？压测的目标有两个： 通过对模块的压测，找到模块的性能瓶颈，分析其资源耗用合理性、架构可扩展性，找到优化方向。 通过对链路的压测，找到链路的性能瓶颈，回答线上资源容量。 压测的技能栈有什么？压测的技能栈要求非常广泛，整体来说，需要具备这些技能： 测试人员的思维习惯和方法论。找到合适的测试模型，并准备好/管理好这些数据。 运维人员的对系统的认识。能够根据需要配置合适的系统资源， 2023-03-05 压测 load test
记一次服务性能的调优排查事情起因： 某一天，听到浩兄说我们有个告警，是因为 event-tracking 的 cpu 使用超标 我感觉比较奇怪，顺口问了下情况，后来又和 浩兄、窦兄 一起看了下各种监控 查看 cpu、内存、网络 情况 发现很奇怪，内存和 cpu 是猛增上去的，但网络流量却非常小。 又听到 浩兄 说当时机器的 socket 连接数被打满了，于是怀疑是 goroutine 的问题，进一步查看 go 2023-03-05
聊聊心力当我们后知后觉地找到了一个自认为 “有价值” 的目标后，就开始了漫长的征途，朝着目标前行。就像长跑一样，知道了自己是参加的 10km 跑后，就沿着跑道一步步前行。 当人有了目标之后，就会产生一系列的精神活动。 有一种精神活动，是通过想象自己已经达到了目标，产生一些快乐，可以认为是提前享受成功喜悦的快乐。这种快乐很有价值，能激励我们继续向着目标前行，但同样，也容易产生一种错觉，觉得自己很快就能达到目 2023-03-05 心力 价值观 信念
grpc的源码走读各包的作用admin 初始化了默认的 channelz 监控，详见 channelz 对外暴露了注册监控 server 的方法 attributes提供了一个简单封装的 immutable kv store 。 authz认证拦截器，提供了 rbac。rbac 模型，使用的是 “github.com/envoyproxy/go-control-plane/envoy/config/rbac/v3 2023-03-05 readingcodes grpc xds
几种后端通信方式的杂谈计算机的几种通信方式对于计算机而言，通信 是一件永远不可能被忽视的事情。通信 基本可以分为 进程内通信 和 进程间通信。 进程内通信的方式大致有： ① 共享内存 ② 变量传递。进程间通信又需要分为 在同一操作系统上 和 在不同操作系统上，同一操作系统上的进程间通信主要有 ① 共享内存 ② 共享存储 ③ 管道(命名) ④ 信号量 ⑤ 消息队列 ⑥ socket 通信。不同操作系统上，则只能使用 2023-03-05 backend communication
service mesh 是如何产生的？演进过程最原始的应用，是由小团队直接负责的单体应用，直观的感受是，团队里的每个人，都对整个项目的技术选型具有影响力(姑且认为 每个人都是 “技术管理委员会” 的成员)。由于仅有一个大项目，也就基本不存在 “平台能力” 的概念。 单体项目逐渐膨胀，分层逐渐模糊、模块逐渐耦合、调用逐渐混乱、发布越发频繁、单个错误的影响面越发增大…… ，这就进入到所谓的 “单体地狱” 阶段。 解决办法之一，就是进行 服 2023-03-05 service istio service mesh linkerd sidecar
