gydtep
发表于 2021-2-23 11:45:08
2016 年出现了第三代微服务架构 - 服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础 能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到丰富的服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等。
gydtep
发表于 2021-2-23 15:30:05
应用通过轻量化的 SDK 来简化对构件 API 的调用，基于 gRPC/HTTP 开放协议可以轻松支持多语言。
s18861353338
发表于 2021-2-23 15:55:28
这么便宜，10G 的值多少钱
gydtep
发表于 2021-2-23 21:38:46
应用托管，相当于应用生命周期的管理，包括应用发布、重启、扩容、灰度发布等，其使用的心智和大家在使用应用或其他 PaaS 平台是一样的，上手门槛非常低。
gydtep
发表于 2021-2-24 10:40:12
云原生已经演化成了一个非常庞大的生态。这张图囊括了云原生里非常多的内容。从设计高可用且稳定性高的应用的角度来看，相关的内容包括数据库技术、云原生存储、Service mesh、可观测性、Serverless等。
gydtep
发表于 2021-2-24 13:23:06
架构设计的另一个重要原则是不过度设计，高可用架构设计应基于业务需求进行。这是因为高可用设计通常极为复杂。比如，将链路中的一些重要业务解耦出来单独部署，无论其业务流量多大，都为这些业务分配一百个节点，从而降低单节点宕机带来的影响。从本质上来看，这些差异化配置通过付出成本和效率来换取高可用，这就存在着权衡难题。从目前来看，很少有软件系统的高可用能力能够实现5个9，大部分都还停留在理论上达到5个9的状态。
gydtep
发表于 2021-2-24 16:30:01
理论上，这种架构设计是可以扩展的。信息流处理和业务流处理被解耦后就可以被部署在不同的节点中。比如，在国际支付时可以将信息流处理逻辑部署在支付方所在的区域中，这就使得支付操作不需要依赖原来的处理逻辑所部署的机房。需要注意的是，在将数据部署在其它机房时，通常需要一些额外的处理，比如信息安全等内容。
gydtep
发表于 2021-2-24 18:47:04
高可用设计通常是静态的，它能够被内嵌到架构设计中，被内嵌到基础设施或者中间件中。高可用设计应根据业务场景实现个性化设计。这要求我们不仅需要关注系统当下的业务特点，还需要预测其未来的业务特点，通过各种特性来刻画该业务对用户的可用性影响。这就需要结合各种原子手段以实现业务在当前阶段所需要的高可用能力。未来，可能存在非常智能的系统，能够使用最低成本刻画业务的当前特征，然后自动化地组合一些原子高可用能力最大化系统高可用能力。
gydtep
发表于 2021-2-25 11:51:44
为了了解这一点，调研机构O'Reilly公司最近对消费者对人工智能的看法进行了研究，其中包括消费者希望看到人工智能在日常生活中的应用。值得关注的是，这项研究可以让人工智能技术开发商深入了解消费者认为人工智能在日常生活中在哪里以及如何发挥作用。
gydtep
发表于 2021-2-25 14:34:23
值得注意的是，很多人仍然不了解人工智能，也不知道人工智能无处不在。其实消费者每天都在与人工智能交互，他们没有意识到预订交通工具、选择电视剧或手机技术都在采用人工智能技术。这是需要改变的现状。
