专家简介

高驰涛 (Neeke Gao)，PHP/PECL 开发组成员，把握近 10 种开发语言，9 年架构师教训，6 年研发治理教训。云智慧 AIOps 社区 PMC，同时也是 PECL/SeasLog、PECL/JsonNet、GoCrab 等多项开源软件的作者。2014 年退出云智慧，致力于 APM 与大数据产品的架构研发，崇尚麻利、高效。

从一个问题谈起

从几年前某 CTO 的一个问题说起：“咱们的零碎将会领有 5000 个微服务组件，咱们应该怎么做？”

咱们都晓得一个接口是无奈称之为微服务的，接口数量达到十几个或者才够称之为微服务。那么，对于蕴含 5000 个微服务的零碎而言，该如何实现和治理呢？

在这样宏大的零碎背地，可预感的肯定存在很大的问题。

微服务的前世今生

微服务是如何诞生的，必须理解以下四个畛域：

TOGAF：全称“凋谢组体系结构框架”，TOGAF 在上世纪七、八十年代的时候就曾经由专门组织负责开发了，直到 1995 年美国国防部参加之后，TOGAF 才最终成型。

现在，大家手机里正在应用的产品和利用中，很多都会用到 SAP、IBM 或者惠普的软件，而这些软件公司所遵循的就是 TOGAF。能够说目前寰球超过 50% 的企业正在应用 TOGAF 实际软件架构设计和开发。

TOGAF 是一个架构体系，但并没有提供具体的架构办法。TOGAF 蕴含了业务架构、利用架构、数据架构、技术架构等。

TOGAF 有三个最为次要的支柱：

1. 企业架构域，次要是企业信息与业务流等；
2. ADM 一系列的架构方法论；
3. 企业连续性，指的是在企业业务高速增长并且一直变更的过程中，保障架构体系的连续性。

DDD：全称为“畛域驱动设计”，其蕴含了诸多的概念，三句话进行概括：

1. DDD 是精简的业务，DDD 首先关注的就是业务，把各种繁琐的业务流程精简成更细的链条；
2. DDD 须要答复业务是干什么的，可能满足什么需要，达成什么目标；
3. 一直迭代，DDD 的一直迭代与 TOGAF 的企业连续性相似。

SOA：全称为“面向服务架构”，实践同样较多，总结为以下三点：

1. SOA 解决了信息孤岛的问题；
2. 业务重用，从业务角度将各个服务组合成一个个中间件或者服务，将其提供给用户或者其余零碎；
3. SOA 使得零碎成为互联互通的信息群。

GRASP 准则：全称为“通用职责分配原则”，蕴含很多耳熟能详的概念如：“低耦合”、“高内聚”，均来自 GRASP 准则。它与设计模式不同，设计模式领导如何实现零碎，而 GRASP 旨在领导如何划分。

GRASP 准则旨在领导定义业务架构以及 API 等相干内容和划分服务，其实践内容也十分多，只须要记住三个要害：

1. 本人干本人的事；
2. 本人只干本人能干的事；
3. 本人只干本人的事，强调了资源划分。

在软件工程的教科书上给出了微服务架构的定义：微服务架构是一种架构模式，它是将繁多应用程序划分成一组小的服务，服务之间相互协调、互相配合，为⽤户提供最终价值。每个服务运行在其独立的过程中，服务与服务间采纳轻量级的通信机制相互沟通(通常是基于 HTTP 协定的 RESTFul API)。每个服务都围绕着具体业务进⾏构建，并且可能被独⽴的部署到⽣产环境、类⽣产环境等。另外，该当尽量避免对立的、集中式的服务管理机制，对具体的一个服务⽽言，应依据业务高低⽂，抉择适合的语言、工具对其进行构建。

而这些教科书上的内容或者在当下来看曾经过期了。

微服务带来的劣势

咱们应用微服务架构的时候，到底失去了什么货色呢？这里总结了四点最为显著的长处：

1. 使得开发和迭代变得更加麻利，应用微服务架构使得麻利开发成为可能；
2. 易于扩大和膨胀，一些公司基于 Kubernetes、Docker 等技术能够在几秒内拉起上万个微服务，当大型流量冲击达到的时候，能够实现无损地承当全副流量，同时实现用户无感知，而当数据访问量升高之后，又能够实现疾速缩容；
3. 多技术栈可能，目前 云智慧的技术栈十分全面，尽管开发人员只有 60 多人，然而开发语言却多达 10 多门，而应用微服务能够无效地组织各类开发人员；
4. 高可修改性，比方实现数据库的疾速迁徙，通道的疾速切换等。

微服务带来的两点疑难

微服务可能带来诸多长处，然而也存在两点疑难：

第一个就是“微服务架构，你的零碎变得更强壮了吗？”；

第二个则是“应用微服务让零碎变得更快了吗？”

对于这两点而言，可能说是见仁见智的。有人说因为组件变得越来越多，可监控性就会变难，因而零碎健壮性就会变得越来越差；也有人说因为将零碎拆分得越来越细，因而健壮性就会越来越强。如果单体架构是串行的，那么应用微服务能够将其变成并行的和分布式的，而多个组件之间进行通信，也会使得通信成为性能瓶颈，那么应用微服务到底是变快了还是变慢了呢？这两个问题都很难以答复。作为一个架构师或者开发者须要一直进行深刻的思考。

微服务架构面临的挑战和思考

这里总结了在应用微服务架构的时候所须要面临的 8 条挑战和相干的思考：

1. 小即是多

当业务从大变小的时候，也意味着业务变多了。由大变小，能够使零碎变得更加容易保护和批改，然而由少变多，又会使得问题更加简单，因而也会呈现很多的挑战。

第一个问题就是多节点、多服务和多状态。零碎中的节点、组件服务变得更多了，那么节点和服务之间的状态也会变得更难保护，更加简单。基于后面提到的四种常识，能够将从大变小和从少变多这两个转变进行折中，使得其变得更加可控。而解决这个问题的关键在于对于服务的正当拆分，次要有三点能够思考，即 数据资源、业务性能以及服务对象。

2. 债权治理

Bug、代码缺点、未实现的性能或者版本不兼容等问题都是债权。当服务变得越来越多的时候，债权往往就会变得更多。

为了解决这些问题，其实有这样的几种策略：

• 单元测试，如果单元测试做的足够好，那么代码缺点的可能性就会变得更低一些，能够将服务由少变多所造成的债权变多状况进行收敛；
• 集成回归，这部分提供了很多工具去做这件事件，不必开发者本人去做；
• 版本治理，这里指的是动态库的版本治理，动静库指的是正在变更中的库，而动态库指的是不再变更的库和配置项，这一点管制不好，就容易使得系统管理凌乱；
• 迭代冲刺，是一种组织形式，当有很多技术债权须要进行治理时，如何将这些债权一点点解决掉或者把发散的趋势收敛住，迭代冲刺就是一种做法；
• Bug Crash，这是智慧云团队本人创造的一个名词，相当于是对于 Bug 的大扫除，无论采纳传统的还是麻利的开发模式，都有一些 Bug 存在，因而定期会组织整体开发和测试以及产品将本人的产品用一遍，进行 Bug 大扫除；
• 回归总结，无论采纳什么开发模式，在一个迭代周期实现之后，回归总结是少不了的，也须要通过一些办法解决新产生的问题，或者将其关闭住不使债权持续蔓延。

3. 简单的服务依赖

如果只有一个或者几个组件，那么其实不存在服务依赖问题，而如果有几千个组件，那么服务依赖将会成为微小的问题。举例而言，如果用户服务须要调用订单服务，那么在启动的时候须要进行一些初始化工作，那么一个服务的版本公布可能导致系统全面瘫痪，这就是简单服务依赖问题。

为了解决这个问题首先就须要 服务发现机制，比方应用 etcd 或者 Zookeeper 等，首先服务发现核心也须要是分布式高牢靠的，那么服务起来之后须要把本人的名字和调用形式通知服务发现核心，注册下来；对于服务调用者而言只须要从服务发现核心那里通过约定好的名字获取服务调用地址即可。

依赖唤醒 是有一个绝对比拟新的货色，比方大流量忽然打进来的时候，A 服务须要从原来的 10 个启动到 100 个，而 B 从原来的 3 个必定也是不够用的，因而须要通过唤醒的机制将服务拉起来，而不是被动的被告诉。

还有一种状况也须要应用到依赖唤醒机制，比方缓存穿透问题，失常状况下，缓存是失效的，不会存在穿透的状况，然而可能因为某种异样使得缓存不失效了，会将大量的流量打到 DB 外面去，使得服务变得不可用了，整个服务雪崩掉，针对这些问题个别会开发一些 挡板服务，可能会给出一些固定的数据，而这些挡板服务也有可能会面临这种突发的流量也须要通过依赖唤醒的机制实现唤醒。

此外，还有 灰度公布和 AB 测试，这两点是相关联的。还有多版本共存问题，对于服务的多版本也是一个技术债权问题，须要思考如何将其旧版本拿下来。

4. 音讯通信

如果零碎中蕴含多个语言栈，多种实现形式。那统一标准是必须的，对立一种 RPC 或者就应用 RestFul API 等。音讯核心也是一种解决做法，这一点在 Java 中利用很多，音讯核心并不是音讯队列，而是一个事件驱动的音讯核心。此外，还有通讯网关，这在应用微服务的时候也是一个必要点，其次要解决了监控问题，而且能够通过网关起到中控的作用，比方平安、性能以及用户校验等工作。

5. 分布式事务

在实现分布式事务的时候能够采纳 2PC 或者 3PC 准则来实现，2PC 准则是通过全副节点投票和执行两个步骤实现的，并且是阻塞的；而 3PC 则不同，尽管在一个具体的事务外面能够是阻塞的，也能够是非阻塞的。3PC 协定则是通过“Can-Pre-Do”三个步骤来实现的，其实 PDU 就是 3PC 协定在单体中的实现形式。而在分布式系统中，3PC 有三种实现形式，应用分布式的事件驱动、最大告诉以及两阶段弥补 TCC。

6. 花式故障

很多时候，当零碎呈现问题可能须要破费数周和很多人力能力找到本源所在，可能因为零碎太多，使得零碎架构师也无奈理清零碎与零碎之间的关系。面对诸多的花式故障，也有多种策略能够应答，比方全链路追踪，比方应用 Open Tracking；被动拨测，很多用户端的 APP 外面内置探针，使其能够接管 Server 端的指令来定期探测接口和服务是否失常。

7. 核心与去核心

核心与去核心能够算是一个永恒的话题，上图中展现的配置、发号、日志、调度、状态以及预警，其实对于比拟成熟的大型零碎而言，这六点都是须要核心的。

8. 组织危机

最初一个问题，也是最大的问题。其实要实现向微服务架构的变更的时候，最大的问题就是组织危机。这一点与开发者关系不大，然而对于 Team Leader 以及组织的管理人员而言，关系十分大。架构的转变须要思考到信任危机、过期保护、多语言栈、沟通合作、平安网关以及轮岗结对等问题。

总结

总结而言，最重要的观点有两个：微服务不是银弹，不要让反复的事件做两次。

写在最初

近年来，在 AIOps 畛域极速倒退的背景下，IT 工具、平台能力、解决方案、AI 场景及可用数据集的迫切需要在各行业爆发。基于此，云智慧在 2021 年 8 月公布了 AIOps 社区， 旨在树起一面开源旗号，为各行业客户、用户、研究者和开发者们构建沉闷的用户及开发者社区，独特奉献及解决行业难题、促成该畛域技术倒退。

社区先后开源了数据可视化编排平台 -FlyFish、运维治理平台 OMP、云服务治理平台 - 摩尔平台、Hours 算法等产品。

优良开源我的项目—FlyFish：

我的项目介绍：https://www.cloudwise.ai/flyF…

Github 地址：https://github.com/CloudWise-…

Gitee 地址：https://gitee.com/CloudWise/f…

请您通过下方链接理解咱们，增加小助手微信（xiaoyuerwie），备注：飞鱼。申请加入开发者交换群，可与业内大咖进行 1V1 交换！