荔枝微课基础架构的演进与实践

本文整理自又拍云举办的微服务架构设计与实践｜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 来了，你了解它么？