一般的app server也需要replication吗？

系统设计的时候，我遇到2个问题，可能没答对
1. app server挂了怎么办？我答，没关系啊，挂了就挂了呗，反正有多个app server -_-
我只知道db server挂了需要backup replication激活，app server挂了也需要这样子吗？为了抢救app server的cache？但现在都强调api 应该stateless啊

2. loader balancer怎么知道app server挂了？我也不太懂，之前我做过一个小系统，我记得loader balancer自己会测app server挂没挂的啊
难道是用doorkeeper吗？

求教系统大神指点

尝试用大白话回答：

1. app server挂了怎么办？

从load balancer的路由配置里面把挂了的节点去掉，不然这个坏了的节点还是会收到请求（然后因为不能做出回应，导致用户看到你的服务一会儿正常一会儿500/502）。然后启动新节点，注册路由，新节点接受传入请求并工作。

2. loader balancer怎么知道app server挂了？

一个是zookeeper等等工具自己会测心跳（heartbeat）。自己实现的话，app server加一个ping的function（无论你是用HTTP RESTful还是GraphQL），然后在load balancer上面定时访问它。

在微软, 运行在Azure cloud services的instances都应该会被要求运行一个monitoring的background job,这个job的任务就是定期向log中心发送heartbeat data, 然后又会有另外一个azure的检测service(watson)去读取该subscription下面所有instances的health的数据去判断哪些instance挂了，所以LB(ACIS service)能够从那个watson得知把traffic从挂掉的region（比如EUS）redirect到healthy的region（比如CUS）。等挂掉的region修复了，就可以重新distribute traffic了。这种failover的前提都是request 得是 stateless的。如果理解有误或者并非best practice，请多包涵，目前本组的service大概是这样work的。

我觉得核心在于：
1. 还有很好的healthcheck API
2. 要恰当的考虑stateless， 尽量使用cache而不是stateful data

可能还要考虑log for debug。。。

实际场景中， api server 可以register to load balance， 让elb来ping。


之前实际工作中的app server挂了的实际场景解决：

如果是stateless
1. 如果是aws之类的vm， 是可以通过auto scaling group 根据预先定义的health check来自动launch新的instane的
2. 如果是container based， k8s自己回launch起pod

如果是stateful：
vm很麻烦， 如果尝试去本机restart
如果是k8s， 要走statefulset， 会自动 mount之前的pv

刚开始准备系统设计说下想法，我觉得1就是要rerouting然后catch up？ 2的话各server之间可以互相发送heartbeat，一定时间没收到哪个server就认为它挂了。
等大神来指点。

我也随便说一说好了..欢迎各位指教
1. 把这个app server暂时从load balancer里面去掉？用consistent hashing分配任务时，不考虑挂掉的app server？
2. ping server或者发个api request，看看有没有在规定时间收到response，如果收到看看response code？

Load balancers have health check. Send requests regularly to servers and check if they could respond timely.

  个人看法：
1. 挂了不要紧，只要你的系统能知道你的APP SERVER 挂了，能够马上起一个新的INSTANCE并且failover即可。e.g., AWS ECS检测到你的CONTAINER炸了自动回给你起一个新的并且fail over。 如果你不用container, 也不用ecs类似的服务，你自己需要实现一个有自动failover的玩意

2. app server提供一个/healthcheck的API，这个api要尽可能的低cost， 并且能较准确的反应你的app是真的healthy.

如果你的app server是负责订单处理的，在处理过程中如果server down了，订单就处于inconsistent的情况

解决方案是在处理完每一个step后，把当前的state存储的storage

server重启后可以进行恢复

请问这方面有啥好的学习资料啊