经过了十个城市的路演，华为HDG线下沙龙终于来到了首都。在北京，开发人员之多，关注的技术领域之广，讨论的话题之深入，堪称HDG历届参与讨论者之最。
作为另一位华为PaaS高级工程师，张琦的演讲内容可以说是得到了开发者极大的关注。在《基于容器的企业级微服务平台》的主题讲解中，张琦总结了华为在微服务构建中的思考和实践，并且结合PaaS平台总结了如何在Kubernetes的容器平台上实现典型的微服务模式。另外对于微服务实施后带来的问题也进行了总结并提供了参考解决方案。
以下是他的现场演讲实录：
今天我讲的主要是微服务，还有企业级、微服务、容器这样一些关键字。在讲这个之前我说一下，现在微服务特别火，不管是企业还是各种技术社区，微服务这个概念都特别火。我不知道大家了不了解我为什么要做微服务，或者我的应用为什么要上微服务，这个问题不知道大家有没有思考过。我刚开始接这个任务，去设计整个微服务平台的时候，对这个问题的概念还是有一点点模糊的。自从有一天我突然看到我这件事情，我不知道大家有没有人骑摩托车，看我后面的衣服，速度***，安全第二。应该不是这样的。
Martn Fowler提出一个观点，跟我的观点非常契合。微服务要解决的问题是什么?***是速度，第二是安全，出发点是速度***。为什么是速度***呢，它说的速度并不是我用了微服务之后我的程序运行更快了，不是这样的。它说的是我的业务要更快的发生变革，我的新业务要更快的上线，基于这个契机才出现了微服务这个东西，才更多的人越来越喜欢微服务，越来越想去实践微服务。第二是安全，它说的安全，我们看微服务，包括看Cloud Native的应用，所谓的安全不是单点安全，不是一个应用就一定要做成最安全的，而是说我整体系统最安全，这里的安全说的是可靠运行，说整体的系统要可靠运行。再细讲有几个方面，一个是可控的，另外就是要有更好的容错、隔离这些机制。所有刚才说的快速开发、快速上线，业务快速变更，保证整体系统的安全、可靠、运行，整体的这一套东西是想你去实践微服务，或者我们看到微服务这个圈子的东西。这是一个题外话，当然这是我的一个思考，不知道在大家的想法里面微服务到底是什么东西，将来大家可以多多交流。
今天我来讲一下华为在微服务，还有基于容器构建这样一个企业级的微服务的运行平台，这里的一些实践，还有一些我们的想法。因为这个讲到了企业级，所以今天的议题是这样的，首先是一个业界技术发展的趋势，还有挑战。另外还有微服务，还有PaaS平台。大家都知道华为的PaaS底下是基于Cloud Native来做的，Cloud Native和微服务有什么关系，怎么变成企业级的平台，这一块会有一些讲解。还有大家很多时候被忽略的一个问题，大家很多时候会认为我上了微服务万事大吉，实际不是这样的。实际上了微服务之后，你刚刚给自己挖了一个坑，后面还有很多很多需要你处理的东西，会带来很多很多的负面效果，这一块我们介绍一下。
首先看一下企业IT技术的应用曲线，这是原图，没有打星的，没关系。我们看这个趋势是这样的，一个新技术出来的时候，企业级的IT对于新技术接受度一直是要迟钝很多的。在企业级之外的，互联网或者其他的一些行业，它会首先接受这个新技术。但是这里面最最重要的是，在接受了一段时间以后，企业级的IT最终或者无奈的接受这种新技术，改造他们的系统，这是一个企业级的IT技术的发展趋势。
我们再看一个现象，2014年很多人认为是企业上云的元年，在2014年的时候几乎没有人考虑我想上docker上我的生产环境，用容器上我的生产环境，绝对不会有人这么考虑。或者说2014年容器根本不可能进入企业级IT的选择名单范围之内。到了2015年的时候，所有人都会把这个容器列为技术研究的一个方向。现在到了2016年的时候我们更看的很清楚了，很多企业级的IT项目现在已经开始尝试在生产环境下使用容器了。
另外的一个趋势是2016年的时候，可以在网上找到这个技术趋势，技术热度的报告。微服务这个词，或者这个技术，已经成为仅次于物联网和认知计算的第三热门的技术。虽然它不是那么高深，那么大的一个东西，但是它已经被列为第三热门的技术。
我们就看这张图，怎么会出现微服务，在微服务出现之前是什么样子的，到底有哪些问题需要解决，所以才出现微服务，就是这条曲线。我们传统的应用大家应该非常清楚，我说的这些产生应用更多的是基于这个企业级的，企业这个领域里面来看的。在企业级的IT的应用里面，它之前的一个应用开发状态基本来说是这样的，首先制定一个统一的产品发布计划，分到各个组，或者是对一个大项目的话，如果我们看到银行项目，看到电信项目，可能各个模块会有不同的承包商，不同的ISV，到一个公司里面可能有不同的开发小组，来承接，来开发。开发完了之后，会有一个集成开发的阶段，大家所有人起来的模块拿到一块再集成开发，经过一轮集成。到***测试发布，发布完的产品要统一找一个产品替换掉在线运行的系统，来统一的找一个时间窗口来进行升级，这是我们在之前的一二十年里面，或者大多数人更熟悉的软件开发或者发布模式。
这里面可以看到一些问题，一个就是我们的产品发布计划肯定是统一执行，统一制定的，到执行的时候又是分开执行，到***又有一个集成的过程。在这个里面，首先各种各样的协调，各种各样的组织，会耗费很大的精力，是一个很大的成本。另外你***要集成到一起，通常大家的开发都会基于一个相同的技术来进行开发，或者相同的技术链，或者相同的语言进行开发，这样才能让你后来好集成。***一个问题，最重要的一个问题，我们很难做到系统永远在线，我们走是需要一个窗口进行隔接也好，升级也好，总是需要做这些。这是传统的系统开发看到的问题。
我们看看微服务化的软件开发，在微服务化的系统开发里面它整个的流程是这样的步骤。首先就是产品发布计划是各个微服务自己来制定的，每一个微服务都按照自己的产品发布计划，自己升级，自己演绎。每一个微服务开发技术都是各种各样的，用不同的技术来开发应用。到***通过DevOps的方式部署生产环境，部署的时候要同步灰度发布或者滚动更新这样的技术，让我整个的系统永远在线。通过这种方式，可以很好的解决刚才说的那些问题。啊
所以我们可以看到Martn Fowler对微服务的总结，微服务的概念最开始的提出是Martn Fowler，但这只是说他对这个概念有一个很好的总结。但实际上在2009年的时候已经实践了微服务，就已经实践的非常好了。我们看Martn Fowler对它的总结是什么呢?服务模块的边界更清晰，这是独立部署，允许技术多样性，这是微服务带来的一些好处。
现在大多数的宣传，大多数技术的讲座，大家都在讲微服务的好处，或者你怎么做到微服务。实际微服务带来的坏处，Martn Fowler同样也有很多的总结。这里列举了一些，比如说分布式编程的大，有风险。首先我们说微服务，我们把一个单体应用拆成一个微服务。其实这件事情并没有那么高深，我们就是把一个普通的应用进行分布式化了。实际上我们就是在构建一个完全的分布式系统。所以对于一个分布式系统来说，对它的管理，对整个分布式系统的开发难度是非常大的。
另外需要处理分布式系统的一致性，普通时候我们做一个单体应用，数据一致性通常是通过数据库的事务解决的。数据库事务很简单，我们只要把所有变化的数据都用一个数据库来解决，靠数据库系统提供的事务就可以保证各个表里面数据的一致性了。变成了分布式系统以后，别说我们用的不是同一个数据库，有可能我们用的都不是数据库，我们有可能一部分数据存在文件里面，另外一部分存在数据库里面。下一个微服务，它的数据可能存在一个MangoDB里面。在这种情况下我怎么保证那个数据的一致性，这是一个非常麻烦的事情。
另外增加运维的复杂性，当然这个还是说一个单体的应用拆成一个分布式系统以后，原来只需要管一个应用，我现在要变成整个系统里面那么多应用，我要管那么多的应用。原来我手工敲一敲命令就可以，现在我管几百个应用，在那儿部署着，在那儿跑着，我敲一敲命令，工作量就变得非常大。这就是微服务同时会增加运维的复杂性。
我们看这个，这是一个(12：55)对于PaaS，还有微服务的一个总结，这张图也非常经典，我看国内有很多公司也会引用这张图。这张图讲的非常清楚，这是整个PaaS系统，包括微服务在整个PaaS系统中的位置。它分成几部分，***部分是所谓的接入层，它包括像ELB、APIgetway。我们的数据请求从前面进来以后，到接入层，继续往后走，再往后有一个(13：38)。这个图是一个逻辑分布图，在实际的运行中有可能整个1和2合成了一个组件，这都是有可能的，但这是一个逻辑的分层。
再往里面走这就是微服务整个的一套的运行环境，3这一块称为源数据管理，源数据管理其实也就是我们非常熟悉的，微服务注册的信息，它的配置管理信息，类似于这样的一些管理组件。4这边是微服务的运行态，就是它的运行时。我们可以看到，这个非常小，就是所谓的负载均衡。在负载均衡微服务的实践里面，很多时候又叫服务发现。就是我想访问一个微服务的时候，这个微服务有10个事例让我选择，我具体访问哪一个事例。这个问题很多时候也可以叫做负载均衡，我就是按照这个负载均衡的策略去访问其中的事例就好了，实际这也是一个服务发现的过程。后面我会详细讲一下。
我们再看看5里面。在一个PaaS系统里面有非常多的服务，刚才我们说的微服务是构成你应用的一个单元。在这里还有一个所谓的后台服务，或者平台服务。如果大家熟悉(16：10)，它对这个平台服务有一个非常好的抽象，就是它通过Service Broker的方式，接入平台外的服务。也就是说一个服务对于一个平台来说，它有自己的生命周期，包括服务的创建，服务和应用的绑定，所有的这一系列的生命周期，它用后面的Service Broker的方式管起来。实际上是一个PaaS平台，它的service更多的是路由的概念，不是平台服务的概念，确实没有。你如果去查CNCF社区，在CNCF基金会里面已经定义了这一套的标准。所以这个PaaS和微服务的模型是非常严谨的。
讲了这些以后，下面这一块，6是所谓的自动化的流程。自动化这一块包括部署自动化、运维自动化，把所有的这些东西都给，直接就叫自动化了，但是这块打开的话还是有非常非常多的东西。7这边是一个遥感，用这个词我觉得特别形象，遥感系统是什么呢?比如说我们的月球车，我们把月球车放到月球上以后，我们对这个月球车撞开的监控，对它出了问题要指挥它修复，不可能人上去再去修复，再去监控，我们必须得靠事先做好的程序去控制它，去做这件事情，这是一种遥感。我们的应用部署以后，跑起来以后也是相同的情况。这个应用只要是运行起来了，就好像我们把这个月球车放到月球上去是一样的。这个时候对于运行着的应用，对于它状态的监控，对它出现故障以后对它的修复，对它一些运行参数的调整，其实就是类似于一个遥感的过程。实际对于微服务来说还有很多微服务相关的监控指标的收集，这个后面也会有一些介绍。我们看***一个，8就是整个系统认证、健全这样的service。
所以这么来看的话，一个版本的PaaS平台，它的最小范围是这个。我们这里说的是最小范围，PaaS平台是什么，或者微服务是什么，现在没有一个逻辑公众的标准。但是如果你想达到预期的目的，就是说我们用一个平台能够整个管理起来微服务，让我们的微服务在里面能够很好的运行，如果想达到这个目的，这样一个系统应该说是一个最小的集合了。
下面我来介绍一下用Kuberentes来构建微服务的平台。刚才介绍的是PaaS平台，最开始我又介绍了微服务，为什么现在带出来这个PaaS平台，带出了微服务以下的这个东西。其实是因为我们看到在一个普通应用变成微服务之后，会带来各种各样的麻烦，各种各样的问题。我们如果还是想用传统的方法去解决这些问题，去管理你的应用，去管理你这个分布式化的应用，实际上难度是非常大的。所以在这种情况下，包括业界很多的公司，它要变成微服务的前提是要把它的东西上云，要把它的东西放到AWS上面去。所以现在的这些云技术，我们总说容器是微服务***的载体，但实际上在实践中你会发现，你基本上是缺不了它的，如果你缺少一个下面的平台，这样的PaaS系统的话，你的系统会变得非常非常复杂，非常非常难以管理，是这样的一个情况。
所以我们来看一下Kuberentes来构建这样一个微服务的运行平台，它有什么好处，或者我们怎么用它来构建微服务的运行平台。上面这个是Kuberentes的一些基本概念，我不知道大家有多少人熟悉这个，人不太多啊，下面我简单的介绍一下Kuberentes。Kuberentes里面有很多概念，我主要介绍一下它对于应用的封装，对于系统的封装，运行时的这些概念，它的管理组件的概念不详细介绍了。Kuberentes跟原生容器不一样的地方，它是一个从出生开始就是为企业级的应用构建来考虑的一个容器平台。所以它对复杂应用，从最开始的设计就进行非常好的考虑。
一个例子，看我们的调度单元，在Kuberentes最小的调度单元不是容器，是一个pod，这一个pod里面可以包含多个容器。这多个容器是共享网络，它们之间可以互相进行一些数据的共享。所以它把它最小的调度单元做成了pod，一个pod里有多个容器，这个就很好玩了，这块可以带来更多的一些设计模式。下面我讲微服务的实现方式里面，也可以借用这样的模式。举一个例子，大家都说容器推荐的是一个容器里面跑一个进程，你实际到生产环境下一个应用不可能只有一个进程的，至少还得有一个agent收集一些运行的情况，至少还得有一个agent去收集日志吧，这种情况下怎么办。实际上Kuberentes用pod的概念可以封装对于这种问题的解决，就是你的主业务在一个Container里面，你的agent在另外一个容器里面，你就可以把多个容器打成一个pod，这就是一个最小的调度单元。
从运行时来说，最主要的概念就是pod，当然它在pod之上还有一些概念，比如说ReplcaSet，原来叫Replcacion Controler 现在新的叫ReplcaSet。它对pod又有一层管理，实际上我们可以认为这是一个pod的动态伸缩管理器。就是一个pod只是一个运行时，我想让这个pod有多少个事例来运行，这是靠ReplcaSet来做的。在这里面定义了我这个调用单元要跑5个事例，就会一直保证它一定是有5事例在跑，如果有更多的事例在跑就杀掉，如果有哪个事例死了，它会再拉起来，这是ReplcaSet。再往上的一层概念就是service，在Kuberentes里面的service，如果我们把它看成路由的话会更好理解。它实际是定义了我的这个应用，我的这个pod怎么被外面，或者怎么被其他的pod发现和来访问的问题。这一块有一点点像微服务里面的服务发现了，这个下面有很多规律，介绍一下。这里面的概念非常多，基本上我们主要理解Container和pod的关系，包括上面Replcacion Controler的概念，还有KPSservice到底是什么东西，基本在Kuberentes里面构建微服务相关的概念就有了。
构建一个微服务，我再讲其他的后面的构建方式之前，要非常非常强调这一点，就是APIfirst，这个有很多人提，但是在很多的微服务框架里面都没有强调这一点，包括国内用的比较多的doubleX，包括现在(27：21)。微服务它声称的一个好处就是，我的每一个微服务都可以用不同的语言去开发。在这种情况下，我在整个系统里面就要有一种定义统一的服务契约的方式。我的这个服务契约是什么呢?就是我作为一个服务的提供者，我能够提供什么样的方式，我这个服务的接口是什么样的，你能通过什么方式来调用，这是整个服务契约。在整个系统里面，如果你用的技术栈也不一样，每个微服务的开发时间点也不一样，你想让整个系统协调在一起的话，特别是一个复杂的大型的系统，API或者服务契约是最最重要的一点。所以这一点要先提。
现在大家用的比较多的一些服务开发框架，可能更多的是靠java的作为一个服务契约的。你想享受到每个微服务由每个技术去开发的话，显然你不可能在开始的时候你的整个系统只有java语言。所以在这一块我们是用IDL，就是谷歌的，用它来做服务契约的定义。用了这种语言中立的方式来定义以后，不管是C语言，JAVA语言，都可以通过这一个契约来进行通信。我们的使用方式在华为微服务的系统里面，我们的使用方式是这样的，我先定义用这种IDL这种方式来定义服务接口，定义完了之后我们有一个自己的编译器，会把它生成相应的各种语言的(29：46)。这块大家熟悉的话能够想到GIPC，实际上GIPC也是类似的方式，但是我们没有用GIPC的原因是说，如果你尝试一下GIPC会发现，它生成的代码可读性非常差，它是包含了服务契约，还有服务通信，所有的东西都砸到里面去了，那个东西是非常难以维护的。实际上我们只是想要一个服务契约而已，在JAVA世界里面***的服务契约就是一个pojo，我们就是想要一个pojo而已，我要那么复杂的东西干吗呢。所以在这里面我们是用了自己的手段，用自己的方式，前面来的服务契约对于java来说就是一个pojo，对于C来说就是一个结构体，我们就是要用这种干净的方式来构建微服务。
我们看一下微服务的实现模式，这个跟刚才容器的概念可以有相关了。基本上是两种模式，一个就是Chassis，所谓的底座模式，底座模式的意思是说我们想实现一个微服务，没有问题，这个微服务它从一个普通应用变成一个微服务，必然有些特殊的东西。我们如果想自己去实现这些特殊的东西，也可以，有这些东西你要去做，包括服务发现、熔断容错、负载均衡、自动化的配置，包括这种通过心跳的方式来报告自己的健康情况，
还有一种模式是Side-car模式，大家知道tricycle ，三轮摩托车，边上的那个边斗，就是Side-car。Side-car用到了刚才我们说的pod的概念，当然这不是强相关的，但是Side-car这种模式的由来是从这块提出来的。它的基本意思就是说我所有做这些东西不用放到我的应用程序进程里面，也就是说我不用你的SDK，我用一个单独的进程做所有的这些事情，你自己的业务逻辑，你自己的应用程序，通过某种约定好的接口，跟我这个独立的进程进行通讯，然后我帮你去做所有的这些事情。所以这种方式在KBS里面是非常方便做的，就是说我可以把这两个东西都可以放在一个pod里面，作为一个最小的调度单元一起进行调度，这一个pod里面的一个容器是我自己的业务逻辑，另外一个容器是我的Side-car。这种方式据我了解在国内也有很多实践。公司名字就不说了，大家如果查网上的技术文章可以看到大家分享的实现方式，国内是有人在这么做。所以我们基本是两种方式都做了，两种方式都用，这种方式更适合的是如果你是一个新的应用，你要开发一个新的业务，完全没有一些负债，你要用全新的方式来做，你当然可以用新的SDK，用新的开发方式来做。如果你有一些遗留系统，有一些遗留资产，遗留代码，你要把它进行微服务化，用这种Side-car模式可能更方便一点，因为你不用一个SDK侵入到你的程序里面，你只要让你的移动应用跟Side-car约定好的这种通讯方式、接口方式来进行通讯就可以了。
微服务里面还有一个比较重要的点，就是所谓的服务注册的方式。这里面就说到服务，一个是应用的自注册，一个是平台注册，这两种方式。我们刚才讲KBS里面的服务，实际上KBS里面的服务是属于平台注册的方式。就是说你在Kuberentes里面可以创建一个应用，创建完应用之后，你再创建一个service对象，就会把这个应用变成一个服务，完全你不需要你应用做什么事情，是平台做的事情。自注册的方式就是你自己的应用，你自己去注册。因为我们刚才有SDK了，在SDK里面处理这个逻辑，我自己上线以后，自己把自己注册上来，变成一个微服务，这就是所谓的应用自注册的方式。
还有注册完之后就要被发现，这边就是说到服务发现的实现方式，实际也是两种，一种是所谓的客户端发现。客户端发现，就是说我的两个微服务之间的通信全都是点对点的，我作为服务的消费者想去找一个服务的提供者的时候，我自己能拿到服务提供者的10个事例，我自己选择一个我这次的通信的事例，跟它建立连接，跟它通信，这是所谓的客户端发现。所谓的服务端发现，就是我自己没有那个逻辑，作为服务的消费者来说，我没有那个逻辑，我不用管这次要跟哪个具体的事例建立连接。我只是把我的请求直接丢给一个中间点，说我要消费一个B服务，你给我找一个建立连接，剩下的它就不管了。
我们看到这种其实更多的是体现了服务自治的概念，每个服务都自治，在运行期间不依赖于任何一个中间节点，这是微服务提倡的一点。而这种方式是依赖(37：34)跟你做服务发现。在写新应用的时候更多的是出现这种方式，如果你是遗留应用，自己本身并不具备服务发现的能力，或者说刚才的几种模式，其中的SDK是刚开始只提供一种语言的，你想用另外一个语言，也要变成微服务。更方便的方式就是这种方式，你不用做系统改善，你只要把请求丢给中间做就可以。KBS里面微服务的实现更多的是这种比较通用的方式，不需要对应用做任何改造的方式。当然各自有各自的好处，所以我们一个完整的微服务解决方案的时候，通常两种都会有。
这块就是一个统一的服务平台，我们构建的，因为在华为公司，它的部门非常多，它的产品非常复杂，刚才我们说的所有的服务注册模式，服务发现模式，都会有适用的场景，所以我们需要构建一个统一的平台，能够支持不同的服务注册方式和服务的发现方式。这块我们就是在Container，借鉴了Container自己服务端服务发现的能力，并且我们做一个自己的Controller，意思就是说Container里面的服务跟我们的客户端发现的，或者是自注册的服务做了一个调节，把两种方式调节到一起，做到两类不同的服务可以互相发现，互相通信的东西，这是我们在Container里面做的东西。好像很多人都不是特别熟悉Container，如果感兴趣的话可以看一看Container自己的结构，都是通过Contreller，APIserver，Contreller(40：09)APIserver去感知到某个对象的创建，自己去为这个对象做一些工作，然后再去改变它的状态，都是这样的一个工作模式。大家感兴趣的话可以看一下。
另外就是在微服务里面要讲应用和配置分离，保证我们的程序可以在不同的环境下来部署，但是不用把包拆开，再去改里面的配置文件。所以我们一般的做法都是会有一个统一的配置中间，来专门管理配置信息。
作为一个企业级的平台，实际还有一些额外的东西需要考虑，就是我们部署的时候有亲和性和非亲和性的调度问题。就是我有些部署要做亲和性，就是我要节省资源，让我的部署密度更大。另外一些应用我想用反亲和性，就是想让我的可用性变得更高，大家鸡蛋不要放在一个篮子里面，这是我们在KBS里面通过亲和性和反亲和性调度，来满足这种场景。
还有一个是Kuberentes的集群联邦，在华为内部的一些应用里面，它的规模是非常大的，而对于Kuberentes来说，社区里现在应该是做到了两千，下个应该要做到五千这样级别的一个node，它的一个noed就是一个虚拟机，在这个虚拟机里面去启容器，当然这个规模是不够的。另外我们会有一些跨云使用的场景，就是一个集群是在私有云里面，另外一个集群是在公有云里面，我要跨云进行交互，这个用到KBS的集群联邦。现在这个集群联邦也是我们团队在Container社区里面来主导的一个开源项目。当然在***的relesage里面就已经有了，1.4里面就已经有了。
下一个我快速过一下，我们刚才讲到了一些用Kuberentes去构建一个微服务平台需要注意的一些关键的点。就像我刚才说的咱们我们管杀不管埋，我们构建了微服务，我的微服务跑起来了，你在前期就要想要它会带来很多问题，最主要的问题就是性能的下降。你把一个单体的服务，之前的业务调用全都是进程间调用，把它变成了分布式系统，跨网络的调用。但是你不管用rest也好，还是用其他的方式也好，网络传输的性能损耗是一定比进程内调用损耗要大的，所以你这个要慎重的考虑选择微服务之间的通信方式。这个图是我从网上找的，它列举了各种不同的通信方式，它的网络传输的效率，包括JIPC，我们可以看到JIPC是这个颜色的，它的性能差距是非常非常大的。所以在你考虑你系统的开放性，和你系统的传输效率来说，你就要做一个权衡。最开始要考虑好到底用什么方式来构建你微服务的之间的通信。
这个没有时间详细讲了，就是我们做微服务的时候要考虑，最开始的时候也说到了，要考虑数据的一致性。我们做普通的单体应用的时候，更多用的是强一致性，也就是数据库的事务。我们到了微服务的时代，用什么方式保证数据一致性的。当然强一致性也可以用，在JAVA世界里面，有WSAT标准，可以使用这种强一致性的事务保障，是这样的原理。大体的原理是两阶段提交，都是两阶段提交，***阶段锁表，第二阶段大家一起提交，中间任何一个地方出错，大家一起回滚，是这样的原理。这种方式一般来说在商业的中间键里面会提供，(46：55)会提供。如果你想用这种方式的话，也可以看开源的选择，包括我们是基于开源来实现强一致性的事务的保证。如果你阿里的实现，在阿里***的Etas里面，是叫阿里where还是什么，也提供了这种强一致性的保证。在企业应用里面，强一致性还是很重要的。
另外在微服务的世界里面，除了强一致性以外，大家更提倡的是用最终一致性的解决方案，而不是强一致性。因为强一致性，刚才我们讲的两阶段提交，它对性能的损失是非常大的。***阶段要把所有的资源都锁住，第二阶段提交成功以后再把资源都打开，在这个过程中你的资源都是锁定的，对性能的影响是非常非常大的。在最终一致性里面，***种方式就是TGC，就是所谓自己补偿的最终一致性方案，你要自己去处理三个阶段，在不同的阶段去考虑到上一个阶段出错了，自己怎么补偿，自己写补偿的逻辑。实际在金融系统里面，如果大家做过银行的系统，金融系统，其实之前很多年数据一致性大家都是这么做的，都是要自己先写一个正处理，再写一个反处理，都是需要这么做的，这就是所谓的TCC的最终一致性。
还有一个是Event Driven，Event Driven就是通过消息队列来实现数据的最终一致性。中间的过程不详细讲了，但是有两点需要考虑的地方，一个就是我怎么保证数据的原子性。就是我一个变化发生了，我要通知另外一边也发生变化，我要把这个变化丢到数据队列里面。我怎么保证在这个变化发生了，本地的数据库已经更新了，还没有往这个队列里面丢，这个时候中间出现错误了，那怎么办，这个数据就不能统一了。所以这块是保证每一个变化操作的原子性，就是自己的变化和变化已经通知出去了，这个过程的原子性，这块是你需要考虑的点。
基本就是这样，我讲的这些点比较离散，但是是我认为最重要的点，在一个PaaS平台上或者在Kuberentes容器平台上怎么实现微服务中的比较重要的一些点。这块我也总结了一下，是我们对微服务的实现，在我们华为里面对于微服务的实现里面来说，除了刚才说的那些那么重要的点，那些最最重要的点以外，还有这么多点你需要去考虑，是有非常非常多点的。你要把所有的这些点都考虑到了以后，都去想好怎么实现以后，这是一个完整的微服务平台。谢谢大家，基本就是这样。
(结束)
