一般的app server也需要replication吗？

Normally Load Balancer would do hearth beat check with App server . When it is not responsive after a thredshould . It's deemed as dead , a new one will be spawned up.  In AWS  a load balancer would be attached with an auto scale group and certain strategies , the number of app servers can be scale up and down automatically  

App server需要有health check endpoint, 这样load balancer可以把unhealthy hosts去掉
App server本身要stateless，每个请求到底给哪个server不影响结果

app server的备份应该是服务层面实现，用备份我觉得不合适LB的health check就很简单了，定时对某一个api endpoint发个request看返回值就好了，aws自己的elb也是这么操作的。理论上说有些监控软件的原理也差不多是这样的。

smallmikko 发表于 2019-4-17 23:55
app server的备份应该是服务层面实现，用备份我觉得不合适LB的health check就很简单了，定时对某一个api en ...

这样就意味着一定的延后。是吧。另外有没有可能health check 工作但是整个服务器却不都健康呢？

mc2 发表于 2019-4-19 01:43
这样就意味着一定的延后。是吧。另外有没有可能health check 工作但是整个服务器却不都健康呢？

第一，这种延迟是可以根据情况调整的，而且正常情况应该也有cloudwatch或者datadog之流对非200的return code进行监控。理论上能做到基本上没延时，只要你不嫌cost太高。
第二，服务器不健康的话，要看哪类了。服务器内存, CPU 或者 disk space 的 usage超级高，那某些api是能跑，某些可能就stuck了，这个时候一般还是靠cloudwatch或者datadog来报警，api检测那套肯定行不通。大多数公司不会就指望api health check来监控自己的服。那如果服务器都没法正常boot，也不用多说什么了。现在的趋势一般都是micro service配上docker，所以针对api的health check其实也够了，毕竟一个container或者POD跑一个api大部分情况是够了。而且cluster的autoscaling一般都是标配，只要服务能deploy，基本上后面除了数据库服务以外，大部分情况不会有问题。