问：你以前没做过手机开发，你觉得你行吗？
答：我入行的时候，PC 机内存 64M，现在手机的内存 128M 。

@fishioon

读取结果数据是 Distribute Service 集中调用 API，成功失败无所谓。
如果成功了，更新缓存数据供其他微服务使用。
如果失败了，记录失败信息，供系统管理员参考，有点儿类似于微服务的健康监控。

所以，也可以看作是在微服务与微服务之间的直接调用路径中加了个间接层，这个间接层顺便还实现了微服务的可用性监控。

@fcten

是的，的确不能把一整套逻辑都写到一个服务里。
不过微服务里也提到说微服务的划分是可以嵌套的，如果按嵌套的方式去设计呢？

比如：先按领域划分大块，就把你说的更新余额相关的，要求实时响应和数据一致的部分，都划分到一个领域，然后再在这个领域里，划分出多个层级的微服务。
至于其他的领域，应该与这个更新余额相关的领域没有强依赖，没有强相关，可以容忍一定程度的异步延迟。

@fcten

海量数据的缓存问题在 [Series data cache] 这篇里有提（好像贴不了网址）。
核心思想就是用某个键值做分块，然后分块缓存，这个参考的 Redis 分布式策略。

所有的缓存都是面向结果的，换句话说，缓存的就是查询结果。
如果查询结果的组合有一千种，就要生成一千份缓存。理论上就是这样的。
但实际上可以二八法则，80% 的常用查询结果能命中缓存就可以了，剩下的 20% 慢点也没关系，可以待预算充足时再加以补足。

更新的时候就是更新了哪个块，就触发哪个块的缓存替换过程。
举个例子：十亿用户分成一千块，查询条件一百种。改了两个用户，触发两个块的缓存更新，就要修改两百个缓存文件。就是这样。

@CoderGeek

差不多吧，主要目的是隔离。
或者也可以看成是多个子系统，而不是多个微服务，后面可以在子系统内部再进行分层的微服务划分。

@miao1007

CPS 不了解，有空学习下，谢谢。

@stevenkang

直接写入数据库的方案的确考虑过，但有两点顾虑：一是数据的频繁更新是否会给数据库造成负担，影响数据库响应其他请求的效率，二是数据库里新旧版本数据的替换速度如何？磁盘文件可以先写个新的，然后交换下文件名，再把旧的删掉。这样数据文件仅改名期间不可用，是瞬时的。

当然，写磁盘文件也有缺点，数据库自带的缓存优化就失效了，查询速度可能受影响。这一点要想改进，可能就得自己打造定制版的 file_fdw 插件了。

@iisky1121

在 Generic Rest API 一文里，查询数据的 url 就可以作为 key，当然 key 太长了可以 hash 一下，ETag Cache Service 里就是这么用的。

@xsen

grpc 也是 RPC 的一种吧。就像楼上有朋友讲的，如果被调用的服务挂了，就返回错误。没错，这样是对的。但有些时候，在数据一致性要求没那么高的情况下，其实可以不返回错误，用旧版的数据继续服务的。grpc 好像实现不了这个目的。

至于说何时不要求那么高的数据一致性，这就看如何进行领域的划分了，只能具体问题具体分析。

@kkeiko

微服务与微服务之间没有网络调用。

Distribute Service 把数据写入到目标磁盘上就不管了，微服务自己读数据，自己用。如果需要跨机房，那就是 Distribute Service 需要跨机房把数据远程写进去，写不进去就先用旧数据将就，直到故障排除。

@xuanbg

是的，消息队列和异步操作可以解决微服务间紧密耦合的问题。

的确是想解决服务间耦合依赖的问题，同时也想降低系统向微服务迁移的难度。

用数据层缓存的方式，可以让程序员不关心微服务调用，不处理微服务依赖，仅使用原始的开发模式，开发 [数据库 -> Restful -> 前端] 即可。这样开发人员的技术门槛就降低了，培训成本也降低了。框架的部分交给框架工程师去处理，普通程序员 CRUD 就可以了。

@fox0001

的确有考虑 CDN，这样就可以超出 docker volume 的系统局限，实现广域网分布式了。

@EmdeBoas

1. 数据只是由一个有状态的服务 (Distribute Service) 负责更新，但数据本身是磁盘上的文件，所以服务挂了没关系，硬盘没挂就可以。
2. 数据的写入，数据的完整性，都由拥有该数据的服务负责，其他服务只能读取。外部服务只能通过消息队列影响本服务的数据。
3. 是的，例如修改密码的操作，用户信息和登录验证层可以是两个服务，总不能让用户无限期等待新密码缓存部署。所以这一块设计了 sync 机制，在密码修改操作返回之前，验证操作所需的缓存就已经部署好了。
这部分内容参见：ETag 缓存服务设计。

@lhx2008

@p2pCoder

关于写入和事务，参见楼上。

1 、写入操作的问题。
大批量的写入操作就应该封装在本服务内部，而不应该由其他服务承担。如果有，也只能是分层关系，而不应是并列关系。
2 、事务的实现。
可以参考这里：
```
PS: 如果需要实时响应，可以在缓存信息表中增加一个 sync 列，sync 为 true 的 URL 缓存会在资源更新操作 (INSERT, UPDATE, DELETE) 返回前完成部署。
```
[https://aiportal.github.io/etag-cache-service]( https://aiportal.github.io/etag-cache-service)

假设 B 服务的某个资源更新操作需要调用到 A 服务的资源更新操作，当 A 服务的资源更新操作成功返回时，B 服务所需的缓存数据已经部署完毕。同样的，B 服务的更新操作成功返回前，该事务应该提供的缓存数据，也已经部署完毕。

微信公众号：招标 123

@rookiebulls 只支持 windiws

@xnode
@tianshiyeben
@Hazurt
@redial39
@kylix
@janxin

行为审计软件，可能概念冷门了点，我添加了介绍。

mark