最后一方面是关于主机商线路的。运营人员在做网站内容更新的时候，偶尔会遇到一段时间网站页面打开慢的情况。若是此时运营人员打开邮箱则会发现收到了来自主机商的线路调整通知邮件，提示这段时间内可能网站不稳定出现百度搜索风险提示。
这种来自K8S而不是应用服务内部的应用运行状态判定逻辑，使得K8S能够掌握应用服务级别的健康状态。
当负载过大时，即使容器进程一直处于健康状态，仍有可能出现该应用服务无法正常提供服务。这种情况，K8S是通过readinessProbe进行检测的。
古人云：“活到老，学到老。”互联网算是最辛苦的行业之一，“加班”对工程师来说已是“家常便饭”，同时互联网技术又日新月异，很多工程师都疲于应付，叫苦不堪。以至于长期以来流传一个很广的误解：35岁是程序员工作的终点。
在我的理解，软件架构主要目标是解决下列挑战：
1、控制复杂性。由于业务的复杂性，需要我们用更好的手段帮助研发组织克服认知障碍，更好的分工协作。分而治之，关注点分离等手段皆是如此。
另外，云原生架构演进是一个持续迭代的过程，每一次迭代都是从企业战略、业务诉求到架构设计与实施的一个完整闭环，整体关系如下图：
容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。
随后开源的 Kubernetes，凭借优秀的开放性、可扩展性以及活跃开发者社区，在容器编排之战中脱颖而出，成 为分布式资源调度和自动化运维的事实标准。
近端在不同场合下可能有不同的名称。比如，如果将会员信息的全部请求都发给应用层，那么其所需要的集群数量将会非常庞大。由于会员信息的查询遵循了较为固定的范式，因此可以将会员信息的查询功能前置到收单服务，从而使收单服务不需要访问会员信息，而可以直接访问会员信息所依赖的服务。这本质上也是通过应用层设计来减小高可用的成本。
云原生应用具有轻量、敏捷、高度自动化等方面的特点，可以充分发挥云的优势，在现代数字化转型的时代，更好地适应业务的发展变化。
有些中大型企业会有多套的测试环境，这些测试环境一般晚上都不使用，在 ECS 模式下，是需要长期保有这些应用实例的，闲置浪费的成本比较高。
在权责方面，面向业务提供服务之前，由统一的团队负责从业务中抽象出源于业务而又不同于业务的数据域，再主导统一建设数据中间层，包括侧重明细数据预JOIN等处理的明细中间层、侧重面向应用可复用维度和指标的汇总数据中间层。
