Supporting gray release need a lot of facilities to make it work and service center upgrading can not apply gray release sometimes. And other scenarios like standalone application(not cloud services) restart is quite common. And base services restart can't influence user's service communication.
------------------ ???????? ------------------ ??????: "wjm wjm"<zzz...@gmail.com>; ????????: 2018??5??14??(??????) ????4:23 ??????: "dev@servicecomb.apache.org"<dev@servicecomb.apache.org>; ????: Re: [Discussion]About service instances discovery reliable problems it's a problem, but why business use gray release, but we reject to the solution? 2018??5??14??????????bismy <bi...@qq.com> ?????? > When service center all instances stoped and then started. This is normal > when we are doing maintenance. e.g. upgrading > > > > > ------------------ ???????? ------------------ > ??????: "wjm wjm"<zzz...@gmail.com>; > ????????: 2018??5??14??(??????) ????12:36 > ??????: "dev"<dev@servicecomb.apache.org>; > > ????: Re: [Discussion]About service instances discovery reliable problems > > > > " When service center restarted" > > that means one instance of SC cluster, or whole SC cluster? > even one instance restart will clear all information? > > 2018-05-14 12:03 GMT+08:00 bismy <bi...@qq.com>: > > > Hi All, > > > > > > Now we meet a reliable problem. When service center restarted, It will > > clear all service instances information. > > And when SDK(java-chassis) queries instance list periodically, it will > get > > an empty list and invocation will fail. > > > > > > In order to resolve this problem, two solutions is suggested: > > 1. service center provide instances persistence mechanism. When service > > center restarted, it will restore instance information, > > and re-calculate the timeout information(e.g. reset instance last active > > time to startup time). If he gets the heartbeat from instance, the > instance > > will not be removed, and after timeout, > > it can removed instances, like the normal way. > > 2. SDK need to take special care with instances remove. SDK don't > > actually remove instances when he gets empty list from service center and > > it will ping the instances. If ping return > > OK, the instance will not removed. > > > > > > Known consequencies: > > Solution 2: > > a. Conflicts with service center white/black rule. > > b. In docker or some instances changed frequently scenario, the ip/port > > is reused by many services when service start/stop, and service health > URL > > may also be the same. So it will give a lot of 400 like error when > > instances is not updated. > > > > > > Any suggestions?