gydtep
发表于 2021-2-8 13:08:58
高可用设计通常是静态的，它能够被内嵌到架构设计中，被内嵌到基础设施或者中间件中。高可用设计应根据业务场景实现个性化设计。这要求我们不仅需要关注系统当下的业务特点，还需要预测其未来的业务特点，通过各种特性来刻画该业务对用户的可用性影响。这就需要结合各种原子手段以实现业务在当前阶段所需要的高可用能力。未来，可能存在非常智能的系统，能够使用最低成本刻画业务的当前特征，然后自动化地组合一些原子高可用能力最大化系统高可用能力。
gydtep
发表于 2021-2-8 13:42:47
未来还可能实现5个9的高可用。首先，假设存在一个和蚂蚁非常类似但又异构的环境，它们之间完全是去中心化的；其次，这两个环境下的数据规则同步应该是可舍弃的，能够实现FO以及全自动的切换；另外，还需要实现监控，监控也应该是异构的，需要有一个外部系统来观测本系统的行为。
gydtep
发表于 2021-2-8 18:19:20
前端智能化算法工程体系升级，引入云原生能力使智能化算法框架 Pipcook 可以从数据侧、模型侧、训练侧、部署侧支持云原生，能够更便捷的融入云原生体系，保障使用者可以直接上线模型算法支撑业务，打通业务的全链路。
gydtep
发表于 2021-2-8 19:10:19
P2C 业务研发平台打造：需求暨代码、需求暨生产、协作在线化的全新业务研发模式。打通需求、设计、研发的全链路，保证信息流转的完整性、迅捷性、连贯性，确保最终交付物和需求的结构化信息的一致性，需求迭代的数据化驱动。
gydtep
发表于 2021-2-8 20:47:27
服务端下沉和抽象化、原子化，提供标准的、原子的领域能力，由 S2C 体系进行能力的理解，并通过需求的约束对调用逻辑：胶水层代码 进行生成。
gydtep
发表于 2021-2-9 07:01:25
线下业务和淘宝业务实际上使用同一个版本进行应用开发和发布，它们的隔离仅仅体现在流量和部署层面。比如，它们所使用的交易服务在开发层面就是完全相同的，仅仅在部署层面将它们的流量分离到不同的服务中。这样，在以业务维度做跨节点的流量绑定时，就需要将几个服务及其节点圈出来进行分流。
gydtep
发表于 2021-2-9 08:53:24
总的来说，对于一个给定的业务场景，高可用设计需要分析它的业务特点，可用性的要求，从而设计对应高可用设计的节点。比如，如何设计以查询功能为主的节点，特别是当其所依赖的数据库不被信任时。在微服务架构中进行高可用设计时，应该针对每个节点的特征进行有针对的设计。
gydtep
发表于 2021-2-9 14:19:21
某节点的配置数据发生变更可能影响其它与之相关的节点，因此这就需要对这些节点做灰度设计，带来了一个链路级的配置灰度设计问题。
gydtep
发表于 2021-2-9 15:10:43
分布式事务中通常有一个发起者和多个参与者。发起者发起一个预提交，在所有参与者确认后，该任务才被执行。这对应着一个二阶段确认过程，即先发起、再确认、后执行。配置灰度设计和分布式事务处理非常类似。
gydtep
发表于 2021-2-9 16:59:11
首先，签约节点发起一个灰度设计，此后和签约节点相关的节点需要参与进来，一同完成灰度。假设灰度的内容是某仓库信息，此时所有参与节点都需要对本节点下的相关数据进行灰度。
