作者回复: 其实就是在CP和AP之间做一个选择。如果用长会话做健康检查，并且用CP方案在注册中心集群内做状态同步，那么就是一种偏向一致性的实现模式。而大部分注册中心在一致性和可用性之间选择的是偏向可用性，AP方案，对一致性采取了一定的容忍，只要最终一致即可。如果要适当提高一致性，你可以调整心跳频率和剔除判定的时间，提高服务剔除的响应速度 微服务下的很多场景都是偏向最终一致性

作者回复: 后面会讲到sentinel的流控和熔断规则，以及扩展sentinel实现基于来源的限流，dashboard二次开发接入nacos做规则持久化

作者回复: 奥利给~

作者回复: 我考虑后面用加餐的方式，添加一部分容器的知识介绍。课程里在日志系统搭建这里也会简单介绍一下docker的使用

作者回复: 可以，不光skywalking，像jaegertracing之类的都可以用（jaeger也是受zipkin启发搞出来的）。zipkin本身不用集成SDK到项目代码里，只要通过sleuth-zipkin插件就可以间接集成，我在项目中会通过RabbitMQ接收链路信息，服务将链路信息发送给RMQ，zipkin通过监听RMQ来获取数据。只用添加三两行配置就能实现

作者回复: 这部分我倒是没有涉及，很多公司是提供了一种平台化的服务来做幂等性检查，接口参数里带有的幂等ID字段，方法先用这个ID调用幂等校验服务做一层检查。我这里所说的平台化服务，就是公司层面开发的供给各个业务方使用的基础服务，比如像ID生成器这类服务。

作者回复: bingo，大体上就是这样。不过更深层次还要考虑以什么角度做服务切分，比如领域建模等等。像大厂里会供着一些领域建模的专家，比如订单域交易域这些核心领域的架构，还是挺吃经验的。 独立拆分部署是微服务表现形式，是表象，不过为了支持这种表象，我们还有很多infra层面的技术支持，这就是后面我们要介绍的各个组件了

作者回复: ID生成器是个很复杂的平台类服务，高并发的ID分发要求分段批量获取+预加载模式，每个发号器预先领取一个号段，在即将消耗完之前从中心节点继续领号。而且对于订单类场景，还要设置特殊的号段分发规则，否则竞争对手可以根据ID来大致估算出你一天的订单量。对于某些金融行业要求的“非跳号”的ID分发就更加麻烦一些。 我们这个练手项目还不需要深入到发号器的业务逻辑，用DB incremental ID简单解决了

作者回复: 这部分没有单独展开讲，优雅退出方案就是尽可能减少nacos instance下线和后台服务下线之间的时间差。这里要结合你的部署方案来看。现在大多公司都会选择k8s容器编排，新建POD然后等完全启动好之后关停老的POD，那么你可以在老的pod关闭之前设置一个hook，主动调用nacos服务的Delete方法做下线/nacos/v1/ns/instance，然后在执行关停POD的操作。