关于又拍云:荔枝微课基础架构的演进与实践

本文整顿自又拍云举办的微服务架构设计与实际|Open Talk 线上公开课，荔枝微课基础架构负责人王诚强做的题为《荔枝微课基础架构的演进与实际》的分享。本次流动还邀请了 Apache APISIX 和又拍云等企业的技术专家分享 API、Service Mesh 等相干实战经验。

近几年，云原生技术和理念失去宽泛承受，泛滥企业开始摸索云原生架构转型落地。本文将会具体讲述荔枝微课是如何做云原生下的微服务基础架构设计。

王诚强，荔枝微课基础架构负责人。次要从事根底技术钻研开发、基于云原生的基础架构设计以及基础架构团队的治理建设。致力于云原生理念下，以微服务搭建中台。

云原生：将来架构的演变方向

云原生（Cloud Native）是将来架构的演变方向，蕴含了一组利用模式，用于帮忙企业疾速、继续、牢靠、规模化地交付业务软件，由微服务架构、DevOps 和以容器为代表的麻利基础架构组成，其中蕴含很多有利于咱们做更多扩大继续演进的理念。我认为云原生是一种文化、一种理念，也是一种生态，既包含技术（微服务、麻利基础设施 K8S），也包含治理（DevOps、继续交付），范畴极其宽泛， 总得来讲是一种围绕云计算时代的架构。

虽说呈现得绝对比晚期的 Spring Cloud 要晚一些，但也是十分先进的，像谷歌最晚期奉献进去的 K8S，之后各大公司也都是在这个开源我的项目上一直去迭代更新，因而它的生态很欠缺。下图中残缺的展现了云原生的整个生态，包含了很多不同的环节，比方数据库，还有音讯流，网关、服务网格等等，这里就不再一一列举了，大家有趣味能够去深刻理解。

云原生的演进历程

2001 年虚拟机进入到了一个可商用的阶段，2013 年 Docker 公布后会发现很多开源我的项目、集体开发者都开始用 Docker 去公布本人的利用；2015 年 CNCF（云原生计算基金会）成立，2018 年 Kubernetes 从 CNCF 毕业，到了 2019 年咱们会发现它已是大家时常议论的热点。云原生开始大热，因为它曾经造成了一个比拟成熟的体系，各大云厂商也开始把本人的云服务、容器服务等开始推向市场，这时大家也不必从零开始自建，这也通知咱们要去把握技术倒退的趋势，懂得借势，而不是什么都是从零开始。

荔枝微课架构的演进历程

荔枝微课架构的演进历程，这里将它分为了五个阶段，如下图所示，咱们具体开展来说。

上古期间：单体架构，业务优先

所谓的上古期间能够了解成公司的开创期间，这时优先以业务为主，如果连业务都没起来又谈何去做更多的技术倒退，这个阶段可能应用单体架构更容易做到迭代。不过它的长处是业务起步快，一个人人多势众就能够把整个我的项目给建起来了，可能就那么一两个服务，它的部署保护也要简略很多，目标就是先把业务做起来。

单体架构的毛病也很显著，一个单体我的项目性能太多，新人就不易上手，我的项目越做越简单，耦合度越来越高，会给前期新进人员带来很多难题，咱们私下称之为“死伤”，不利于扩大新性能。其中最麻烦的是前面的新人要去接手并发展新性能，如果代码品质有问题，可能一个部分 BUG 就会影响到整体。而且有很多曾经实现的性能，会重复使用到新的业务中，比方领取、账号等这些同样的性能，难道又要从新做一遍吗？

不过上古期间的整体架构也不肯定只有一个服务器、一个服务，也是有一些伸缩性的。上图中的 Users、Threads、Posts 形成了整个单体构造的利用，它是可复制的，比方在负载平衡上面挂多个。另外它是无状态的，所谓无状态是指不会因为多一台服务伸缩进去而导致服务不可用，其中须要特地留神的是一些须要设置白名单的，比方 IP 白名单，多一台机器，可能 IP 就对不上了，会导致其余的环节报错。不过这能够通过一些软件设计的办法，比方代理、生产生产这种模式去解决。

初期：初步微服务，解耦化

初期阶段单体构造会变得越来越简单，保护起来也会越来越难。设想一下，一个零碎外面可能有几十甚至上百个不同的模块，不同的文件夹，一个新人看完这些代码都须要花很多的工夫，又谈何理解整体并做保护呢？甚至整个要跑起来所要理解的常识也很多。因而前面就须要会做解耦化，也就是咱们所说的初步微服务化。不过初期还是由业务来推动的，这个时候的指标还是拓展不同的我的项目，解耦的话也不会一步就到容器化。该阶段须要先对服务做松耦合，不便新人进来后去保护代码，另外就是做很多像监控这类兜底的能力。

说到服务做松耦合（解耦），因为晚期没有很好的兼顾，很多利用是解耦了，但它的技术栈多而杂，甚至连部署形式也都不一样，如果是原来保护我的项目的开发人员走了，由你来接手，它的语言、框架、部署形式都不同，保护工作会很难进行。 拆分后也会面临到服务关系问题，服务少的时候还能明确服务之间的调用关系，当服务多了后，调用关系就会比拟乱 ，特地是为了不便调用，疾速上线将配置跟代码混合一起的状况，这样拆分后反而会带来更多麻烦。因而上古期间以业务为主，须要掂量一下是否拆分，业务有没有这个需要，不能因为做拆分而影响业务，另一个是如果人员不够也不适宜去做拆分，保护起来会更麻烦。

整体式架构拆分如上图所示，这里写到是 Container Ports，与以前相比更理想化了一些，须要先进行容器化，拆分之后将 Users 服务、Threads 服务、Posts 服务别离对应不同的 API 入口，别离去扩大会更利于去保护。比方负责 Posts 开发的，就只需专一于这一块。

畛域驱动设计与微服务

拆分中有一个词叫畛域驱动设计（Domain-Driven Design，简称 DDD），是一种由域模型来驱动零碎设计的思维，最早前的还是通过数据库等数据源来驱动零碎设计（Model-Driven Design，简称 MDD）。畛域驱动则会划分业务和性能，比如说领取、订单或者是用户等，拆分后的可复用性就更强了，互相调用就能够。畛域模型是对业务模型的形象，畛域驱动设计绝对比较复杂，有趣味的能够去深刻理解，总的来说规划设计不是变化无穷的，按本人最适宜的来就好了。

拆分后也会面临一些问题，因为服务变多了，部署、治理、资源布局会特地麻烦，冀望每一个微服务有本人的专用数据库，后面说到了要掂量是否拆分，规模很小的话做这个是得失相当的，应该先把量做起来，比方单表过亿、超大量了，对数据库做组成、只读、读写拆散、分表都没有用的时候再去思考分库。而且拆分之后应用了专用数据库，它们之间的调用会是个麻烦，特地是分布式事务，上面会再具体解说。

中期：深水期改革，实现集群化

中期是集群化的过程，也能够说是容器化。 我集体认为在过后的工夫节点上，程序可能是反了，应该是容器化做得越早越好，这样解耦的时候会缩小很多不必要的麻烦 ，当然这个也跟历史工夫的趋势有关系，可能之前没有趣味，大家感觉这个技术不成熟，不敢用，因而还是按老的形式解耦。但如果是当初还未发展这些工作，须要之后再去做的，是能够把容器化提前一些的。

对咱们而言，中期要做的是要把初步微服务化过程中存在的一些问题纠正过去， 须要对立配置核心，拆散代码和配置；对立开发测试流程，对立继续集成继续部署形式，做容器化、集群化革新，提供更为全面的监控告警体系 。尽管在初期微服务化时也做了一些监控方面的工作，但既然进到了云原生，相比在单台的 vm 机上做监控，模式会不太一样，然而理念都是相通的，须要降级到更适宜集群化上的监控告警能力。

改革都是向云原生聚拢的，具体措施在于初步微服务化后，通过引入 K8S 以解决服务治理、资源管理问题，并进入云原生生态，这样很多货色都能用起来，防止反复建设；引入 DevOps 解决自动化流程问题，包含自动测试、代码品质评估、构建、部署等；引入 Istio 解决网关和服务治理问题。

当然上述这些改革能够依据本人的状况去适配，不过也会面临一些问题。咱们不仅要着眼于软件架构，还须要有更多基础架构的视线，有些问题须要基础架构的能力去解决，又或是软件架构能解决但实现起来特地简单的，这时交给基础架构去做会简略很多。另外，设计如此多的革新、变更开发设施流程须要更多的跨部门沟通与资源，造成成本增加；革新后也会带来一些危险，须要检测评估出台兜底计划。此外，革新中要用到很多新的货色，须要咱们继续一直的学习去吸取常识能力始终往前走。

云原生利用与传统利用的区别

云原生在一个更好的根底平台与设施上提供了更多的利用。因为做了容器化就不须要指定操作系统，K8S 的资源调度更有弹性，之前须要通过代码来协调实现伸缩策略，比拟麻烦，借助 DevOps 会容易达成合作，因为它整个流程都是主动的，可能麻利开发。还有微服是都是各自独立的，具备高内聚、低耦合的准则，具备自动化运维、疾速复原的特点，自愈能力强。当集群宕掉了，它会主动拉起，比方之前深夜业务故障可能须要定位到哪个服务宕掉了，再重新启动起来，当初就不必这么麻烦，它会主动从新挂起，用户甚至都不会感知。

如上图所示，原有架构是没有集群化的，比拟乱；新架构做了集群化，甚至是做了网络隔离。说起网络隔离，有些公司可能感觉没必要，当测试环境跟生产环境在同一个网络，会引入一些不确定的因素，如果是下面的利用呈现破绽，有可能会被挖矿，甚至影响到生产环境，而网络隔离能无效的避免这种状况。 新架构的劣势在于通过集群化的过程能够实现有序治理、平安隔离，性能也更弱小 ，像下面说到的自愈、资源编排等，生态也更加好了。当然咱们不仅是关注内部服务，其余云原生上的利用能够间接通过 Helm 之类的去装置。

再提到 DevOps，这是通过不同的环节去建设的，从编码到上线监控做服务治理，都是按下图的流程走完，到前面的能力也越来越强。在编码开发环节，关注的是代码仓库、代码品质，像代码品质监测，是之后一步步去往上加的。测试也是一样，最早是本人做一个性能去测试，前面加了很多自动化测试的伎俩，比方压测，能够保障代码上线的品质。

大家兴许会感觉上线之前加那么多环节，那迭代速度不就变慢了吗？其实这是一个谬误的认知，真正会变慢的是代码品质不行，带着 BUG 上线，发现后回滚甚至可能会间接带来损失。这要是放在在以前的工厂，这种叫返工、召回，会更加影响效率， 只有胜利的公布才算是有效率的迭代 。

构建环节最早是本人把文件、代码、环境依赖等打包好，传到服务器，须要依赖服务器的自启动伎俩去保护利用。做了容器化后，通过容器镜像，打包成镜像，它的环境会处于一个隔离的状态，不易受到影响，再利用 DevOps 的 pipline+K8S 去公布。环境做了更明确切分，公布模式从最早的灰度到能够滚动降级。

监控方面，最早只有日志采集和 statsd 监控，上了集群后就有 prometheus 去提供更多的监控信息。告警环节，从最早的邮件到企业微信，当初能更间接及时地收到事件信息，sentry 把报错收集过去，就能够及时定位到问题。剖析也是这样，如果对流程不相熟，出问题后查找定位可能要花很多工夫来剖析，而当初做到了一键剖析、慢查问剖析、RDB 剖析，甚至监控曲线更智能的剖析，当然当初云厂商发售的服务器也会提供这些能力。

上线治理中，最早是当发现某个服务有异样，除了在 LB 负载平衡调权重，没有其余更好的方法，只能通过代码发版去做降级。有服务治理之后，就能够在这一层做像熔断之类的解决，例如有 K8S 之后，资源的调度、伸缩都更自动化了，再引入 Istio、链路追踪、访问控制等能够失去更好的增强。

分布式事务

分布式事务是绝对本地事务而言的，而数据库本地事务有 A（原子性）、C（一致性）、I(隔离性)、D（持久性）等四大个性。艰深来讲就是一次性把所有事件打包做完，它是一个分布式的。说到分布式必定要提到布鲁尔定理（CPA 定理），具备 C (一致性)、A (可用性)、P (分区容错性) 的个性。

了解了概念之后能力提出更好的解决伎俩，因为 CPA 中实践上没有网络提早，而理论事实里是有的，所以在 CPA 定理上加一个 BASE，即 Basically Available(根本可用)、Soft state(软状态) 和 Eventually consistent (最终一致性)，能够了解是对 CAP 中 AP 的一个扩大，这些更切合实际的实践在 BASE 中用软状态和最终统一，保障了提早后的一致性。

– 分布式数据库： 能够间接进行解决，但因为分表机制不太一样，可能会带来一些麻烦；

– TCC： 即 Try、Confirm、Cancel 模式，它不依赖关系数据库，然而要按模式去实现 TCC 接口；

– 事务音讯： 咱们所知最多的就是 MQ 音讯队列也能够去做分布式事务处理，因为它能够在不同的服务之间做异步的告诉机制；

– 本地的音讯表： 通过定时轮询或 Binlog 去触发，放弃两个库或两个服务之间的一致性，前提是接口必须幂等性。

前期：服务网格化，进步服务治理能力

解决掉中期的麻烦后，前期则须要进步服务治理能力。之前是让一个利用起来很简略，可能一个命令就能够，当微服务扩大了很多利用，拆分的服务越来越多，每个服务的状态都要治理，这时治理会变得越来越简单，所以这阶段会进行服务网格化。当然这个工夫程序不是相对的，当你足够理解齐全把握了，就会明确像云原生 K8S 跟服务网格其实是能够合在一块的。

这里用了 Istio 官网上的介绍，智能管制服务之间的流量和 API 调用，通过不同 API 的流量管控能够实现红 / 黑部署，也称为蓝绿部署、金丝雀部署。它提供建群、流量增发，可能实现不同版本、不同服务之间流量比例的管控，能够观测，具备全链路追踪的能力。

在有老服务、新服务的状况下，能够在流量管控的能力上做流量转移，过程像是一边行驶一边换轮胎，用户从内部拜访，咱们在网关这层做一个规定判断 。如果合乎规定就走新服务，比方白名单或者灰度去匹配，进入集群走新服务去运行；如果不合乎则走默认的，即原来的老零碎。

将来：继续演进，永无止境

将来会是一个继续演进的过程，永远不会停留，没有什么最完满、最现实的架构，最现实的架构就是它能够一直的去演进。随着咱们整个世界的技术潮流，它也会一步步往前推，而不是停滞不前。有些概念后面没有提到，比方 Servceless、中台等，通过业务中台、根底中台、数据中台的拆分来提供一些更通用的性能，还有像 AIOps/NoOps 都是在前面能够去演变的。 总之，技术计划总是有很多种，适宜本人、适宜现阶段的就是好的。

如何确定架构方向

架构的方向始终是围绕需不需要、方不不便、稳不稳固、适不适宜等开展的。 单体架构也不肯定不适宜，次要看业务、老本、效率是否须要，如须要则是能够保留的，或是当达到了肯定规模有需要时再去思考。在思考如何布局架构时，能够从研发效率、扩展性等方面思考是否更不便，当然最要害的是放弃稳定性。

微服务的五大准则

• 不要构建微服务，即不要为了微服务而微服务，视理论状况而定
• 不要在没有 DevOps 或者云服务的状况下进行微服务，要趁势而为，借力打力
• 不要通过使它们变得太小来制作太多的微服务
• 不要把将微服务转变为 SOA
• 不要尝试成为 Netflix，不须要什么都从头开始

架构的评估办法

• 性能测试，比方网络耗时
• 压力测试，检测架构破绽和需改良的
• 定期演练，定期检测
• 团队、用户是否称心，要依据反馈一直的改良

从一年前的事变频发到两头一段时间的误报，这个过程咱们也做了很多改良，因为毛刺会间接影响咱们的判断。还有些是第三方平台事变，针对第三方的问题首先是要沟通迫使对方去改良，再者本人也做好一些灾备计划，比方抉择更多的单干商。往年咱们步入安稳增长期，基本上就没有毛刺了。

以上是王诚强在又拍云 Open Talk 公开课上的次要内容分享，视频观看、PPT 下载请点击

举荐浏览

看视频常见的 720p、1080p、4k，这些分辨率到底蕴含了什么

HTTP/3 来了，你理解它么？