了迹奇有没

敏捷开发中有一个广为人知的开发方法就是 XP（极限编程），XP 提倡测试先行，为了将以后出现 bug 的几率降到最低，这一点与近些年流行的 TDD（测试驱动开发）有异曲同工之处。在最开始做编程时，我总是忽略单元测试在代码中的作用，觉得编写单元测试的功夫都赶上甚至超越业务程序了。到后来，业务量越来越复杂，慢慢地，浮现一个问题，就是系统对于测试人员是一个黑盒，简单的测试无法保证系统所设计的东西都可以测试到。

公司的某款游戏在1月初接入微软小冰AI聊天功能。为了保存聊天记录并为后续的统计功能做好准备，决定将聊天记录存放在服务端。

帮助你更好地理解和实践系统设计细节！

http状态码是状态码，而不是错误码，是可以完全利用起来的。有的开发者认为，只要是预期内的错误，比如参数错误，都是可以用200返回的，然后在内部用isfailed来进行判断。目前国内的大小厂、第三方，都是统一返回200的，或许是出于一些业务考虑，可行，但并不一定最优。使用code在约定上会规范一些，更好统计。经过一些实践和积累，对错误处理进行阶段性的总结。结构体中，正确为统一一套结构体（业务返回）。预定义错误统一返回http状态码为400。其他（主要是500）为预期之外的异常。

1. 设计高质量代码优化Map使用读写锁，读写锁 读多写少（存储用户连接信息）map不要太大。2. 突破系统瓶颈 优化连接数linux下的系统最大连接数3. 降低对Cpu资源的使用降低io 降低json使用一次编码 多次使用4. 降低对IO资源的使用合并写数据库次数优化对数据库读操作能缓存就缓存5. 应用/资源服务分离系统提供动态服务文件服务迁移到OSS...

在k8s中，节点的调度主要由亲和性和污点来进行控制的。 而在亲和性部分由分为了节点亲和性和节点反亲和性。 节点亲和性是指在pod部署时，尽量(软策略)或者必须满足(硬策略)部署在某些节点上。 而节点反亲和性就是指，在节点部署中，对具有相同标签的pod不会部署在同一个节点中。配置方法：yaml：apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: sele.

在 《微服务架构设计模式》 一书中，作者总结了关于微服务的一些“重点”，原文如下： 中国企业和开发者对微服务架构的热情让我印象深刻。但如同我给所有客户的忠告一样，我想对本书的读者说:    第一，要记住微服务不是解决所有问题的万能“银弹”。    第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。    第三，关注微服务的本质，即服务的分解