gydtep
发表于 2021-2-6 14:08:41
容器镜像迅速成为了应用分发的工业标准。随后 Google 开源的 Kubernetes 因为其优秀的开放性、可扩展性和活跃的社区，在容器编排之战中脱颖而出，成为分布式资源调度和自动化运维的事实标准。
gydtep
发表于 2021-2-6 21:17:59
个人比较倾向于后者，WASM/WASI 可以成为一个跨平台的容器实现技术。近期 Solo.io 推出的 WebAssembly Hub 就是将 WASM 应用通过 OCI 镜像标准进行统一的管理和分发，可以很好地应用在 Istio 服务网格生态中。
gydtep
发表于 2021-2-7 14:02:38
在数据库方面，如何解耦核心和非核心业务的DB。在业务链路方面，由于微服务具有复杂的业务场景和节点，这些业务场景和节点间如何混合，业务节点如何支撑业务链路，容量不足时哪些业务场景应优先通过，限流时应优先限流哪些业务等也是解耦需要关注的内容。总体而言，解耦原则要求将最核心的业务链路隔离出来，使其与其它业务间的耦合尽可能小。
gydtep
发表于 2021-2-7 14:36:35
应用程序可能有多个机房，如果多个机房间存在数据冗余，那么一个位置的错误就能够由另一个位置的数据来弥补，从而保证系统的持续可用。读写分离也是一种冗余设计，缓存和DB间存在数据冗余，当缓存宕机时，可以从DB回源到缓存。
gydtep
发表于 2021-2-7 15:21:59
异步要求将业务流程的核心部分抽象出来，使其不与非核心的内容耦合。从理论上看，核心部分越精炼，系统出错误的概率越小。比如，支付宝的支付业务背后有一百多个业务处理节点，在微服务时代，其背后可能有几百个甚至上千个业务节点，假设每个节点的可用率都是5个9，把几百个甚至几千个节点的可用率乘起来就会使得整体的可用率非常小。
gydtep
发表于 2021-2-7 15:34:55
但通过移除和核心业务无关的内容，从而减小节点数量后，系统的可用率就会大幅增高。上图的左右两边从不同角度对微服务的高可用设计进行了分析。左边是微服务设计应具有的能力，右边是设计高可用微服务架构时应遵循的原则。
gydtep
发表于 2021-2-7 16:09:25
另外，有三块内容实际支撑着一个微服务系统：代码、配置和数据。其中，代码和配置是相辅相成的，代码执行的间歇可能需要修改系统配置；业务数据也非常重要。对这三块内容进行分析是微服务架构高可用设计的重要方面。
gydtep
发表于 2021-2-8 10:41:30
如果此时将FO库作为主库继续进行修改，那么最终得到的数据必然不是用户所预期的。一个处理方式是将持续往黑名单库里写差异。当主库宕机时，首先将FO库拉起来，此时，这些差异可能使得FO库中某一部分数据是禁写的。
gydtep
发表于 2021-2-8 11:29:34
对用户信息这样的业务而言，每天只有很少的数据会发生更改，并且用户信息发生宕机的概率很低，因此这种处理带来的禁写对业务的影响非常小。通过这种方式强一致地写黑名单库，能够近似地实现无损的容灾设计。回切数据库时也是如此。由于FO库已经有很多新的数据内容，因此在回切数据库时需要将这部分数据merge回主库中。
gydtep
发表于 2021-2-8 12:26:34
即使在云原生时代，一个业务场景的高可用架构设计也仍然需要许多操作来共同实现。未来，这些与业务无关的设计可能被组件化地沉淀下来，成为基础设施。
