2018-03-21 14:10

　　ServiceComb跟微服务有比较密切的关系，刚才陈屹力提到会做微服务的相关标准，现在由我给大家简单介绍一下，华为开源的微服务框架。

　　我来自华为公司开源中心，是阿帕奇项目的发起人，有十多年参加Apache项目开发、孵化的经验，现在也是它的成员。

　　今天主要给大家介绍一下ServiceComb项目的背景，以及跟其它微服务框架的区别。还会介绍ServiceComb最近发展的路线图，以及如何加入ServiceComb社区。

　　前面提到微服务和容器是密不可分的，微服务架构现在也是一个比较流行的架构，但是微服务架构正面临什么样的问题？我们现在逐一解读。

　　首先作为传统单体的应用，各个服务都放在一个进程中，各个模块如果要升级的话，是一个很痛苦的事，牵一发动全局。把应用按照微服务的方式拆开之后，为了能快速应对业务的发展需要，我们把它的部署和开发方式发生了一些变化，按照单独进程的方式来部署，会带来一个好处，升级部署的时候会容易得多。但实际上以前一个进程，但现在十几二十个进程也很痛苦，现在云化技术可以比较好的解决部署运维的问题，包括现在K8、CNCF里很多项目都是帮助做这件事。

　　但拆开之后会面临另一个问题，因为服务与服务之间是跨越进程的交互。我们借助云化技术，还会面临一些服务器的地址是不固定的，要启动的时候才知道。这就要通过服务的注册发现机制来解决这个问题。另外这个服务也许什么时候就没了，不能假定这个服务是一直可靠的，所以我们需要提供容错、熔断的机制。我们在服务运行的过程中，资源的消耗是动态发生的，这时候我们可能需要通过限流降级的功能去帮助我们应对流量的变化。

　　业务的发展需要我们提供支持7×24小时服务保障和动态路由的机制。微服务架构虽然能让我们业务跑的很快，但我们还是面临着网络化、云化所带来的分布式系统的问题。另外运维也是我们需要解决的问题。面对这两个微服务架构带来的问题，一是程序员角度来解决，另外是运维人员角度来解决，大家解决问题的思路是不太一样的。

　　从程序员的角度来讲，这个时候我们就有大量的服务框架了，一般来说，像Netflix的开源套件、Spring Cloud、Dubbo等，这些都是从框架层面帮助我们解决前面所面临的那些分布式系统网络所造成的问题。如果用框架来解决的话，为每个语言都要做一个框架，这是很痛苦的。有没有一个好的解决办法呢？从运维人员角度来讲是可以通过服务网格来解决这个问题。为什么我们能通过服务网格做这件事呢？很大程度是我们微服务之间的交互是通过网络进行的，一旦通过服务网络接管之后很容易做到对应的服务限流降级，服务的容错熔断，也可以实现服务的动态注册和发现机制 。那服务网格是不是一招鲜全部解决呢？其实它只是给出一个比较好的解决方案，不需要对每个语言做一个框架，但会带来性能和部署的问题。

　　我去年ServiceComb项目立项时，就面临了如何为ServiceComb定位这个问题。一个是传统的这种服务框架的实现方式，另外一种是新型的服务网格的实现方式，这也就是我们为什么会存在雄关漫道的主要原因。

　　现在大体介绍一下ServiceComb到底是什么? ServiceComb项目初始的核心是需要直击微服务所面临的痛点问题，简化微服务开发以及运维的难度。 ServiceComb项目也不是凭空出现的，它来源于华为云服务引擎的框架，这个框架在华为内部经历了大概两年多的商业化运作，积累了电信领域的高性能低延迟的能力，在华为商城也历练过，我们积累了大量的微服务、云化的经验，其实相当于是云能力的下沉。

　　通过开源微服务的框架，我们在开源过程中也跟很多的用户进行过交流，发现大家在用云、容器、微服务其实都不是很了解，这个时候其实还存在教育大家的问题。所以ServiceComb这个社区也扮演了这个角色，这里面提到我们针对于行业的话还会有一些解决方案，包括微服务脚手架都在做这样的工作，帮助大家从传统的应用到改造成为微服务，并且部署到容器或者云环境中。

　　我们把ServiceComb定位为开源的微服务解决方案。下面给大家简单介绍一下解决方案所包含的内容，我们主要提供了传统Java语言的框架，也提供了Go语言的框架，这是侵入式的框架。另外我们也提供了不需要改代码的方式通过ServiceMesh进行接入方式。同时为了降低用户开发成本，我们也提炼了一些在云原生开发过程中所常用的一些架构模式，包括我们可能需要有一个边缘的服务，帮我们去对接外部的Restful请求转到内部RPC的请求。同时我们也抽象了微服务的常见架构， 通过这种脚手架、语言模板的方式来帮助大家生成一些基础的工程文件。

　　大家只需要按照业务需求把对应的代码填进去，就可以做基础的微服务开发。同时针对云化、容器化也给大家做了很多的示例，包括怎么用Docker，生成的云怎么上传上去，有一整套的解决方案帮助大家做这件事。在运维方面也提供了动态配置，同时针对微服务事务一致性问题，我们也提供了Saga事务一致性的解决方案。

　　ServiceComb也对接了大量的开源项目，我们不但对接了Spring Boot和Spring Cloud， 还对应了携程的动态配置中心阿波罗，以及分布式追踪系统Zipkin。

　　ServiceComb在去年11月份的时候，加入了Apache的孵化器来进行孵化。 Apache基金会在成立二十多年的历史中做了很多事情，一个最主要的是发布大家都广为知晓的Apache软件许可2.0，除此之外Apache软件基金会在开源社区治理方面有丰富的经验，现在Apache软件基金会管理的项目大概有三百多个，这个要比CNCF要多很多的。ServiceComb进入Apache软件基金会孵化最主要的目的是想学习Apache软件基金会规范化的开源项目的运作，以及丰富的社区运营经验，来构建一个健康的开源的生态。

　　我们现在有三个子项目进入了Apache，一个是Java的底座，提供了高性能的微服务框架，然后来提供服务的注册发现以及动态配置。另外是服务中心，建立在高性能服务的基础上。还有就是Saga 提供分布式一致性解决方案。

　　这是ServiceComb Java底座架构图。通过服务契约我们可以明确定义服务提供方能够提供哪些服务，这些服务调用的参数是怎么样的，服务执行过程中会抛出什么的错误。

　　提供了服务契约的核心，针对服务运行过程中所需要提供的具体服务，以及服务调用参数，都有所体现。还有一系列的工具来帮助你生成接口文档、框架和调用代码。服务契约是建立在OpenAPI基础之上的，OpenAPI提供了一组与独立与具体语言框架的 API描述语言，来规范RESTful服务开发。

　　Java语言底座支持多种RESTful服务的编程方式，即支持应用广泛的Spring MVC与JAXRS编程模型，也支持POJO + 服务契约的开发方式来描述RESTful服务。。

　　Java语言底座通过通信模型对外进行交互，其中包含了消息序列化和反序列化的模块以及底层传输的模块。值得一提的 Java Chassis的通信模型是建立在Vertx基础之上了，内部已经完全异步化了，微服务在全异步工作模式下有很高的性能。

　　ServiceComb Java Chassis借助VertX提供的异步内核，在4C8G的虚拟机上能提供5万以上的TPS调用， 为了能够在支持异步调用的同时支持同步调用，我们把通信线程和业务线程分离，同时针对单个业务也提供了隔离仓的方式来保证系统的安全稳定运行。。

　　分布式的事务一致性，简单说一下以前事务一致性是通过数据库的方式实现，但在分布式的情况下，每个数据库都是服务自己的，所以我们不能通过数据库的方式来实现。我们需要在应用层实现一套事务管理协调机制，来帮助我们实现这个事务的最终一致性。

　　ServiceComb提供了一个名为Saga分布式事务解决方案， Saga 这个词来源于30年前的一篇数据库论文， 在论文中一个Saga事务是由多个本地事务所组成， 每个本地事务有相应的执行模块和补偿模块，当saga事务中的任意一个本地事务出错了， 可以通过调用相关的补充方法恢复之前的事务，达到事务的最终一致性。在ServiceComb中我们将Saga本地事务的概念， 替换成为了分布式服务调用。为了保证Saga事务的最终一致性， 我们需要通过Saga协调器来追踪各个分布式事务调用的执行情况，当相关的子事务执行出错了，  Saga协调器会自动执行相关的恢复操作保证分布式事务的最终一致性。

　　与其他的分布式事务一致性方案相比，Saga在简化事务配置以及提供多种事务恢复机制上有很明显的优势。

　　最后简单回顾一下ServiceComb的发展线路图。

　　ServiceComb从2017年的6月份发布了第一版，包含了服务中心和java底座，之后每隔两个月发一个版本。Saga是2017年9月份发布的0.0.1版本。

　　下面是我们进入Apache孵化后的新的版本。 我们进入因为我们进入Apache做了很多的准备工作，让这个版本更加规范，这个月底应该能发出来的是1.0.0的M1版本。对于Saga来说有一个新的版本，狼群实现，通过Saga的协调器来协调事务的执行情况。

　　后续我们将在响应式编程、生态的支持、微服务的管理控制、服务中心方面会继续发力，同时服务网格在不久的将来也会开源出来。同时针对微服务Saga的实现，也会在服务端的高可控性、同步异步的支持，也会做一些努力。

　　最后是如何加入到ServiceComb社区，可以扫旁边的二维码，会添加ServiceComb的微信小助手，帮助大家拉到交流的微信群里面。旁边是我们的官网，里面有我们快速入门手册，用户指南以及一些内幕。还有是跟大咖说也有一些合作，差不多是隔两周会举办线上的一个直播活动，会给大家公布一些台前幕后的信息。

　　另外如果大家在软件使用过程中发现了问题，可以通过Apache JIRA反馈，也可以给我们的邮件列表跟我们互动。如果想看我们的代码，可以在Github 的Apache组下面找到我们项目的地址。最后我们在微信群里会给大家推送一些线下的Meetup活动，如果大家加了那个微信小助手的话会有提醒。

　　我今天的演讲到此为止。谢谢。