开发者例会议题收集（202208）

[chuntaojun]

开发者例会议题收集（202208）

会议信息

andrewshan(单家骏) 邀请您参加腾讯会议
会议主题：Polaris社区开发者双周会
会议时间：2022/08/16 19:30-20:00 (GMT+08:00) 中国标准时间 - 北京
重复周期：2022/07/12-2022/10/04 19:30-20:00, 每两周 (周二)

点击链接入会，或添加至会议列表：
https://meeting.tencent.com/dm/kBemx9IzxmGE

#腾讯会议：701-1815-5065

复制该信息，打开手机腾讯会议即可参与

议题列表

• 英特尔同学讲解 polaris-security 以及 polaris-sidecar 中相关代码设计
• polaris-sync 架构讲解 @andrewshan
• 动态负载均衡功能的规划
• console 与服务端的访问凭据转为 JWT（已有社区同学处理）
  • feat: change client token to jwt token polaris-console#91

[chazex]

Hi， 动态负载均衡，计划在哪个版本加呢？

[andrewshan]

没有看到有issue，能详细讲一下你们场景么？

[Guo-Zhang]

1. 这周正好在搞Auth，如果需要补充相关知识可以讲下。
2. Mock方案不太顺利，目前我有几套预案，都不太有可行性，我打算再想想，不过也可以讲。

[MI-cool]

polaris-sync采用的sync-config文件配置太粗糙了，生产环境上百微服务根本没法使用

[chuntaojun]

polaris-sync采用的sync-config文件配置太粗糙了，生产环境上百微服务根本没法使用

polaris-sync 只是一个同步工具，如果要用户上百微服务的话， polaris-sync 后续会支持一个类似管控的组件，用于下发拉起 polaris-sync

[andrewshan]

大佬可否详细描述下生产环境下这样的配置方式可能遇到的问题，毕竟polaris-sync当前只是第一个体验版本，需要大家多反馈优化

[Guo-Zhang]

猜测是缺少对批量配置的有效支持。

首先需要明确下微服务数量是什么原因：

1. 微服务规模比较小，甚至完全FaaS化。
2. 整个系统规模非常大，需要上百个微服务支持。
3. 多租户，比如支持私有化的时候。

不同的情况需要的解决方案不一样。复杂系统里是需要复用一套的同时自定义各个微服务的配置（我也需要这样的机制），比较建议用模板方法的设计模式。如果是多租户，可能更需要的是更加云原生化的配置，把配置解耦地更干净一些方便给用户调整。

探究可用性不好的原因，可能需要先了解微服务系统的大概情况，然后是同步过程中遇到的坑，比如手动配置100遍，或者是其他的问题。

[MI-cool]

多种服务注册中心间数据同步的场景阿里那边有个nacos-sync，它使用数据库保存需要同步的微服务，有可视化页面，比配置文件更直观易操作。
不过，从架构设计上，nacos-sync是部署了一个中心化数据同步集群。或许是我用错了，polaris-sync的设计预期是分布式的？

[andrewshan]

嗯，polaris-sync当前初版是使用配置文件来作为任务下发通道，但是模型是固定的，模型设计上考虑了大批量服务的场景。

后续可以支持管控端，通过管控端来做任务的拆分和下发给sync，同时也可以支持可视化界面，可能要看看社区的节奏。

你说的中心化和分布式指的是？

[andrewshan]

我加个议题，polaris-sync架构设计讲解

[Guo-Zhang]

建议同时增加一个对它的使用场景的头脑风暴（如果能够记录下来并且变成测试用的代码以及文档的教程/最佳实践最好），用来验证架构是不是有效的。

[andrewshan]

polaris-contrib/polaris-sync#2

[Guo-Zhang]

I. 为什么需要Mock？

跑真实实例时，增查删改有一定可能会相互依赖和冲突，这样就不方便先单元测试再集成测试。

假设我们只考虑写一个CURD，只需要一个集成测试就可以完成。如果我们希望对每种CURD的正常异常情况都详细覆盖，那么单元测试Mock各种情况、先确认单元没问题以后再验证集成，往往效率比较高。

II. 目前可以考虑的Mock方案

1. 设法用文档生成Mock。主要的问题是需要有文档可用。

目前有几种方案：
（1）手动重写一遍。如果社区有同学能做就不是问题。
（2）用代码解析文档的源码，先大概生成一个，然后再手动维护。可能是最具性价比的方案，但可以预期的是解析不好写。
（3）从源码里导出一个文档，再根据需要维护。这个需要动Provider的源码。

这几种我都可以出详细方案，如果社区能找到同学愿意做，我可以带一下。

2. 从头写Mock。等同于手动写API文档，而且还不方便在各个语言的SDK里复用。不过好处是进度可以相互独立，如果赶进度可以考虑，不过我这还不赶。
   （1）Python里通过标准库unittest的patch装饰器，直接把代码运行的上下文替换掉。这种方案内部不透明，可能有风险，不过HTTP问题不大；好处是代码不太需要动太多。
   （2）Flutter/Dart里需要通过静态工具生成代码，把Client换成MockClient，然后使用MockClient代替Client在单元测试里写。这种方案更透明一些，不过代码需要改动比较多，维护本身也比较费事，我最近写的比较烦。

[chuntaojun]

目前社区已有同学开始处理北极星 OpenApi 中 OpenApi DOC 文档处理了，以后会随着北极星的发布，一并发布 OpenApi Spec Doc

[Guo-Zhang]

cool! 我这边根据这个信息update一下我对mock的想法