Nacos应用

• 我们定了一个标准规范，新的项目尽量统一链接公共的Nacos进行配置管理
• 命名空间用来区分不同的项目，例如花西子、相宜本草、产品线......
• 分组用来区分不同的产品，例如OMS、WMS、TMS......
• 数据集用来存放配置信息，例如数据库连接、缓存配置、RabbitMQ配置......

Nacos集群无中心化的坑

• Nacos集群是通过nginx统一负载来实现无中心化的，客户端只需要知道Nginx的IP和端口即可，不需要过度关注Nacos。
• 但由于无中心化，Nginx本身是不知道Nacos哪个节点上主节点的，因此Nginx无法将请求转发给主节点。
• Nacos集群节点自身内置了一套强大的“请求转发”机制，他们自己知道自己是主还是从，当从节点收到消息，会告诉客户端主节点的地址，然后客户端会重定向主节点，从而访问到主节点（同时客户端会在短时间内缓存下这个地址）。
• 由于我们使用的云服务器不一定全是一个网段的，但由于Nacos集群节点的重定向机制给的是主节点的内网地址，导致访问失败。
• 解决方式：需要在每个Nacos节点的配置文件中conf/application.properties，添加一个对外访问地址的参数。

OpenFeign应用

• 我们在使用OpenFeign的时候，会将Feign接口设计成一个独立的jar包，并且包含各种DTO对象。
• 然后让客户端和服务端都依赖此jar包，服务端实现此接口，客户端调用此接口。
• 以此保证了接口的一致性，并且避免了重复定义DTO对象，避免了DTO对象不一致导致的错误。

接口中心

• 接口中心，需要配置各项目的字段映射，原本打算直接在配置中心进行配置，但是众多项目的字段全都不同，并且经常修改。
• 最开始，因为不确定字段所属层级，因此使用递归的方式，将配置文件进行解析成一个map对象，然后对比配置中心中的字段，将字段进行映射。
• 但我们发现这种方式太过于缓慢，而且为了保证配置文件即改即生效，每次我们都得重新加载配置文件，就导致接口效率更加慢了。
• 最后我们找到一种方式，利用自定义的类加载器，将配置文件直接编译成class直接加载到jvm中直接运行，这样执行效率会提高很多。
• 要实现类的实时生效和旧类卸载，关键在于为每个版本创建独立的类加载器，这样旧版本的类就可以随着类加载器的回收而被GC。
• 再之后，我们计划后续有时间将替换更可靠的框架来替换这个方案。

后续计划：

• 为每次编译分配唯一版本号，记录编辑日志，允许用户手动回滚，实现优雅降级。
• 监控告警：监控类加载器数量和内存使用情况，防止bug导致内存爆掉。

Sentinel对于接口中心的流控

因为我们需要控制每个商家的流量，我们使用的是热点参数下的QPS限制，将商家的ID作为热点参数，以限制商家流量

由于接口中心会承担所有的数据流量，所以我们接口中心使用的集群模式

Sentinel如果想要监控集群，就需要一个独立的Token Server来统一进行计算，默认情况下Sentinel会直接由客户端自己计算

并且我们也考虑了给Token Server做集群，但实际上，Sentinel的Token Server本身并不是无状态的，它的集群高可用方案并没有官方正式发布

虽然社区和实践中有一些思路:在客户端配置中，可以指定多个Token Server的地址。客户端会按顺序尝试连接，直到连接成功。这样，当其中一个Token Server宕机时，客户端可以自动切换到另一个。但是，这种方式有一个问题：多个Token Server之间状态如何同步？Sentinel默认没有提供状态同步机制。

因此Token Server集群并无法解决高可用问题。

最后我们找到一个比较适合我们的解决方案，也是市场上比较常用的方案：不做Token Server集群，而是部署多个Token Server，每个Token Server都负责一个业务线，比如淘宝的部署在聚石塔服务器，京东的部署在云鼎服务器，拼多多的部署在多多云，既保证单独的Token Server宕机不影响其他业务线，同时也保证了各自全都是内网连接速度快。

敏捷开发（推行原因：项目卖不动，公司压力剧增，需要每天看到进度，大的任务经常半个月没进展）

初期盲目的执行，但多数同事根本不了解OMS，最终一塌糊涂，效率没有任何提升，bug越来越多

后面发现，敏捷开发的前提是需要团队对项目的了解非常深才适合，因此，我们开始对团队分组，将特别熟悉项目的三四个人拆分出来作为一个攻坚组，专门做大任务拆解敏捷开发，团队中其他成员只负责项目基础的搭建，然后进行集成，这样，团队对项目了解越深，效率越高。

同时严格定节点，避免产品设计占用开发时间，开发占用测试时间