kimoti2021-12-28想请教老师为啥要保持一致性？作者回复: 比如说，一个妹子被劈腿了，她要跟渣男分手，分手这个事儿分两步，1）扇渣男一巴掌 2）吼一句：给老娘滚！ 这两步一气呵成缺一不可，如果你只删了一巴掌，渣男还一脸懵逼都不知道这是为啥。所以两件事儿都做完了，才达成目的，要做都做，要么都不做。这就是事务的一致性 事务不一致的情况很常见，比如巴掌扇了，“滚”始终没有勇气喊出来，这种情况怎么办？这就是我在后面课程将要讲到的，如何用seata组件保证事务的一致性，同学敬请期待。
共 7 条评论20
gevin2021-12-27老师，请教个问题。用nacos做服务注册时，如果有些服务时本地起的，有些是docker起的，那么默认情况下，docker起的服务，nacos中的注册地址是docker内部IP，本地起的服务，nacos中注册地址是本地服务器的IP，这就导致了本地服务访问不到docker服务的问题。 对于这个问题，现在用的比较多的解决方案有哪些？作者回复: spring.cloud.nacos.discovery或者spring.cloud.inetutils下可以指定宿主机IP，我一般本地测试就用这个方法，再设置docker网络用host模式，这样就可以共用同一个物理机
共 2 条评论12
Lee2022-05-11请教老师一下，如果在a服务调用b服务的时候，b服务挂了，好像探活是有时间间隔的，万一刚好在这种时间间隔中，怎么处理作者回复: 既然是AP倾向的系统（可用性优先+最终一致性），不可能保证100%的调用成功率，作为调用方要做好一致性保障。比如说两个强绑定的先后调用，如果一致性要求非常高，可以改成分布式事务，或者事务型消息，也可以在上游做重试+记录日志表+补偿job等方式容错
10
梁😜2022-01-14为啥要保持一致性？因为Nacos 是一个需要存储数据的中间件，因此就需要在 Nacos 内部实现数据存储。单机下其实问题不大，简单的内嵌关系型数据库即可；但是集群模式下，就需要考虑如何保障各个节点之间的数据一致性以及数据同步，而要解决这个问题，就不得不引入共识算法，通过算法来保障各个节点之间的数据的一致性。作者回复: 同学说的没错，像共识算法也是面试里经常被问到的问题
9
Mars2021-12-30我们现在用的是eureka+apollo做的企业级的注册中心和配置中心。作者回复: apollo也很稳，国内用的挺广泛的，我自己感觉比spring cloud config好用
5
暮雨yl晨曦2021-12-27我们部门原先用的是gRpc，不好用。无论是调试还是写proto文件都很麻烦，我记得我第一次用这玩意，搞了好几天才跑通。现在使用的用dubbo居多。我们正在考虑要用SpringCloud Alibaba，我想要深入了解一下这块。正好看到现在的课程，就买来顺手学一下。作者回复: gRPC太难用了，protobuf坑很多，而且有时候自定义新属性的时候，新手很可能不知道要“追加”新属性，而是删除之前老的上线属性加塞一个新属性，造成各种线上问题。横向比较淘系的hsf还有阿里开源的dubbo，确实开发维护成本上来讲grpc有点坑
5
起开我要掉渣了2021-12-28速更速更+++作者回复: 这位同学你先坐稳扶好，别急，男人嘛还是要慢~慢~来~ 太快不好 车门已焊死，不学完你不能下车！
共 2 条评论4- gevin2021-12-27远程服务调用，本质上都是RPC；但是，RESTful这种架构风格，统一了双方的通信契约，如，统一用http作为通信协议，URL均面向资源，用http方法映射为资源的CRUD，http code 反应API的语意，用json或xml做完数据的载体等，这让RESTful对开发人员更友好，也方便了异构系统等集成，所以，微服务架构，用RESTful架构风格设计API最合适
作者回复: 我也比较喜欢http rest调用，国外公司用的会比较多。相比hsf, dubbo这类在国内比较流行的框架来说，另一个在国外流行的grpc真的是太难用了，定义protobuf就够喝上一壶。不过dubbo集成成本更低，丢一个api就能给上下游依赖方做远程调用
4 
一步2023-03-10 来自广东group 一般会怎么用呢？ 一个微服务一个 group 吗？ 比如：用户服务 user_group ，订单服务 order_group作者回复: 举几个简单的例子吧，如果我想做线上灰度测试，那么我可以把一组服务发布到group A，网关层切一部分流量到A，这些流量就在group A内的服务间被消费。小公司也可以用这个机制做简单的热点隔离，比如说专门组一套hotkey group，当识别热点数据产生的时候，通知网关把特征流量导入hotkey group的服务中，这个区服务被热点打挂了也不会影响主要区域。 其实只要涉及到”分组“需求的，都可以变通来使用，freestyle
3
~2022-01-09nacos 的领域模型和数据模型感觉我搞得不是很清晰，讲一下自己的想法，老师麻烦纠正一下。 1. 数据模型我还明白点，从 namespace 到 group 再到 service ID，就是颗粒度不断减小的趋势。从开发环境或者租户隔离，到每个环境下不同分组（这里的分组看了9节的内容，感觉就是用来在 namespace 的隔离基础上自定义的隔离，比如namespace 作为租户的隔离，那么 group 就可以作为每个租户的环境隔离），再到 group 中的每个微服务（例如项目的 template 服务，calculation 服务，customer 服务，这种具体的服务）。 2. 领域模型就有些搞不懂了，实例就是每台机器提供单独的服务，集合起来就是一个集群，但是之后的服务我就有些不理解，是一个「服务」包含那张图以下的集群吗？那么服务这个「定义」是向其他的服务提供服务吗？还是我理解的：一个集群通过「服务」向其他集群请求、响应，这里的「服务」就是一个中转站。 写的有些乱，我自己也有点捉摸不透，还麻烦老师回答一下，谢谢！作者回复: 1. 同学理解的不错，通常情况下namespace用作租户隔离的情况比较多，因为大厂里经常会在不同环境下配置单独的nacos集群。比如测试环境和生产环境，这两个nacos一般不会混用。 2. 领域模型DDD其实是领域建模，并不是物理集群的意思，而是微服务拆分的范畴。说如何把一个庞大的业务，根据各自的业务属性和边界，分拆为一个个独立的领域，构建领域模型。比如我们经常听到的支付域、订单域其实就是顶层域，然后再逐渐向下分拆。
共 2 条评论3