本帖最后由 李白云 于 2018-4-28 09:25 编辑【作者】文/华为云微服务引擎团队 【摘要】近年来越来越多的企业开始实践微服务，本文分为上下两篇介绍微服务框架ServiceComb如何帮助企业应用进行微服务化，实现快速交付，并可靠地运行在云端。上篇介绍ServiceComb的服务管理中心设计。 【参考】打造一个企业级应用的微服务开发框架（下）---ServiceComb通信处理详解 近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：微服务框架是否具备高可靠性，任何时间不能中断业务；微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，性能下降不会太多。本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架SeviceComb如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。上篇先介绍微服务的服务管理中心。从服务注册中心到服务管理中心1 整体介绍13886图1 ServiceCenter整体介绍ServiceCenter是一个具有微服务实例注册/发现能力的微服务组件，提供一套标准的RESTful API对微服务元数据进行管理。ServiceComb的微服务注册及动态发现能力也是依赖其实现的。除了以上描述的微服务动态发现外，ServiceCenter帮助应用具备以下能力： [*]支持微服务实例隔离管理 [*]支持微服务黑白名单管理 [*]支持长连接监听微服务实例状态变化 [*]支持OpenAPI规范微服务契约管理 [*]支持微服务依赖关系管理 [*]提供Web portal展示微服务管理界面 [*]高可用的故障处理模型（自我保护机制） [*]高性能接口和缓存数据设计 2 管理的需要作为微服务系统中非常重要的组件。当前可选来做微服务注册中心的组件很多，例如Zookeeper、Consul、Eureka、ETCD。然而这些服务注册中心组件的重点在于解决服务的注册和发现，也就是一个动态路由的问题。而在一个大型的微服务架构的系统中，除了这些动态路由信息外，还有一些微服务自身的元数据同样需要进行管理，所以我们定义出微服务静态元数据。通过ServiceCenter提供的接口可以很方便的检索微服务信息。除了微服务本身信息属于静态元数据外，ServiceCenter还扩展了微服务依赖关系、黑白名单、Tag标签和契约信息等元数据，他们之间的关系如下图所示：13887图2 微服务相关静态信息之间的关系这些微服务元数据不仅把实例信息分组管理起来，同时也满足了用户对微服务管理的需要。比如说微服务的黑白名单，业界的服务注册中心大多仅实现了consumer服务依赖的服务实例发现，但没法对一些安全要求高的服务设置白名单访问控制，ServiceCenter支持给这类provider服务设置黑白名单过滤规则，防止恶意服务发现并DDoS攻击。3 分布式系统的高可用性保障微服务及支撑它运行所需要的系统，从广义上来看，是一个典型的分布式系统。而分布式系统就一定不能逃脱CAP魔咒：Consistency(一致性), 在分布式系统的各点同时保持数据的一致。 Availability(可用性), 每个请求都能接受到一个响应，无论响应成功或失败。Partition tolerance(分区容错性)，当出现网络分区故障时系统的容错能力。C和A是每个系统都在努力追求的目标，但是P又是不能完全避免的。想同时满足三者是不可能的任务。此后应运而生的BASE理论便成了现代化，特别是互联网分布式系统设计的准则：BASE理论，Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）；ServcieCenter本身作为实现微服务架构中服务注册发现的组件，对整体微服务系统起到至关重要的作用，并且其本身也是一个分布式的系统。因此后面我们通过对一个微服务系统中常见故障模式的剖析来介绍在CSE中对BASE的实现。 3.1 常见的故障模式13888图3 常见的故障模式 这里列出了ServiceComb架构中常见的故障以及对应的自保护机制，由于后端存储使用ETCD，本身也有一定的故障恢复能力，具体可以访问官网了解；现在简单了解下ServiceComb SDK（简称：SDK）和ServiceCenter是如何实现高可用的。 SDK：1. 与ServiceCenter网络分区：SDK提供实例缓存机制，保证业务继续可以用。2. 业务实例不可达：SDK提供客户端负载均衡能力，快速将请求路由到可用的业务实例，同时也支持提供一系列的容错策略，控制流量继续流向异常的实例。 ServiceCenter：1. 进程异常：ServiceCenter提供监听127.0.0.1的本地HTTP健康检查接口/health，当监控脚本调用该接口时，ServiceCenter内部会进行etcd可用性检查、当前管理资源容量超限检查和平均延时等检查。当以上某个指标发生异常时，接口将返回错误，便于监控系统及时感知。2. 环境约束：一般有CPU负载高、内存不足和磁盘空间不足等因素，ServiceCenter针对环境不稳定或资源不足的场景，除了自动触发自保护机制以外，还有提供一些可定制策略尽量保证自身可服务在这类环境中。如：针对CPU负载高的环境，ServiceCenter支持配置请求读写超时，最大限度保证请求可以正常处理完毕，针对磁盘空间资源不够场景，ServiceCenter自身提供定时日志压缩转储能力，尽量减少磁盘空间占用。3. 并发操作：针对并发向ServiceCenter发写请求场景，需要保证数据一致。为此ServiceCenter利用了etcd本身提供数据强一致性能力，保证每一次写操作是原子操作；对于复杂的分布式业务场景，ServiceCenter内部还提供了分布式锁组件，防止分布式并发写数据不一致的问题。4. 网络分区：微服务依赖常见问题，一般是依赖的服务不可用和相互之间网络故障问题。针对前者，松耦合设计，ServiceComb SDK（简称：SDK）和ServiceCenter均有提供缓存机制，保证运行态下，SDK到ServiceCenter、ServiceCenter到etcd各段间互不干扰；针对后者，ServiceCenter除了提供常见的客户端重试外，还提供异步心跳和自我保护机制。可见ServiceComb从设计上已经考虑了高可用，下面分别从SDK到ServiceCenter和ServiceCenter到etcd两个层面来说明ServiceComb如何实现的。3.2 保护机制3.2.1 从SDK到ServiceCenter1. 实例缓存机制基于SDK开发的微服务，会在第一次消费Provider微服务时，会进行一次实例发现操作，此时内部会请求ServiceCenter拉取Provider当前存活的实例集合，并保存到内存缓存当中，后续消费请求就依据该缓存实例集合，按照自定义的路由逻辑发送到Provider的一个实例服务中。这样处理的好处是，已经运行态的SDK进程，始终保留一份实例缓存；虽然暂时无法感知实例变化及时刷新缓存，但当重新连上ServiceCenter后会触发一缓存刷新，保证实例缓存是最终有效的；在此过程中SDK保证了业务始终可用。13889 图4 微服务实例缓存机制2. 心跳保活机制ServiceCenter的微服务实例设计上是存在老化时间的，SDK通过进程上报实例心跳的方式保活，当Provider端与ServiceCenter之间心跳上报无法保持时，实例自动老化，此时ServiceCenter会通知所有Consumer实例下线通知，这样Consumer刷新本地缓存，后续请求就不会请求到该实例，也就微服务的实现动态发现能力。这样做的好处是，解决了业务某个实例进程下线或异常时，依赖其业务的微服务实例，会在可容忍时间内，切换调用的目标实例，相关业务依然可用。13890 图5 微服务实例心跳保活机制3.2.2 从ServiceCenter到etcd1. 异步缓存机制在ServiceCenter内部，因为本身不存储数据，如果设计上单纯的仅作为一个Proxy服务转发外部请求到etcd，这样的设计可以说是不可靠的，原因是因为一旦后端服务出现故障或网络访问故障，必将导致ServiceCenter服务不可用，从而引起客户端实例信息无法正确拉取和刷新的问题。所以在设计之初，ServiceCenter引入了缓存机制。13891图6 异步缓存机制1) 启动之初，ServiceCenter会与etcd建立长连接（watch），并实时监听资源的变化。2) 每次watch前，为防止建立连接时间窗内发生资源变化，ServiceCenter无法监听到这些事件，会进行一次全量list查询资源操作。3) 运行过程中，List & watch所得到的资源变化会与本地缓存比对，并刷新本地缓存。4) 微服务的实例发现或静态数据查询均使用本地缓存优先的机制。异步刷新缓存机制，可以让ServiceCenter与etcd的缓存同步是异步的，微服务与ServiceCenter间的读请求，基本上是不会因为etcd不可用而阻塞的；虽然在资源刷新到ServiceCenter watch到事件这段时间内，会存在一定的对外呈现资源数据更新延时，但这是可容忍范围内的，且最终呈现数据一致；这样的设计即大大提升了ServiceCenter的吞吐量，同时保证了自身高可用。2. 异步心跳机制中心化设计，另一个难题是，性能问题，基于心跳保活机制，随着实例数量增加，ServiceCenter处理心跳的压力就会越大；要优化心跳处理流程，首先了解下ServiceCenter怎么实现实例心跳的。实例心跳，主要是为了让ServiceCenter延长实例的下线时间，在ServiceCenter内部，利用了etcd的KeyValue的lease机制来计算实例是否过期。lease机制的运作方式是，需保证在定义的TTL时间内，发送keepalive请求进行保持存储的数据不被etcd删除。基于这个机制，ServiceCenter会给每个实例数据设置下线时间，外部通过调用心跳接口出发ServiceCenter对etcd的keepalive操作，保持实例不下线。可以知道，这样设计会导致上报心跳方因etcd延时大而连接阻塞，上报频率越高，ServiceCenter等待处理连接队列越长，最终导致ServiceCenter拒绝服务。13892图7 异步心跳机制在这里ServiceCenter做了一点优化，异步心跳机制。ServiceCenter会根据上报实例信息中的心跳频率和可容忍失败次数来推算出最终实例下线时间，比如：某实例定义了30s一次心跳频率，最大可容忍失败是3次，在ServiceCenter侧会将实例定义为120s后下线。另外，在实例上报第一次心跳之后，ServiceCenter会马上产生一个长度为1的异步队列，进行请求etcd，后续上报的心跳请求都会在放进队列后马上返回，返回结果是最近一次请求etcd刷新lease的结果，而如果队列已有在执行的etcd请求，新加入的请求将会丢弃。这样处理的好处是持续的实例心跳到ServiceCenter不会因etcd延时而阻塞，使得ServiceCenter可处理心跳的能力大幅度的提高；虽然在延时范围内返回的心跳结果不是最新，但最终会更新到一致的结果。3. 自我保护机制前面提到的缓存机制，保证了ServiceCenter在etcd出现网络分区故障时依然保持可读状态，ServiceCenter的自我保护(Self-preservation)机制保证了Provider端与ServiceCenter在出现网络分区故障时依然保持业务可用。现在可以假设这样的场景：全网大部分的Provider与ServiceCenter之间网络由于某种原因出现分区，Provider心跳无法成功上报心跳。这样的情况下，在ServiceCenter中会出现大量的Provider实例信息老化下线消息，ServiceCenter将Provider实例下线事件推送到全网大部分的Consumer端，最终导致一个结果，用户业务瘫痪。可想而知对于ServiceCenter乃至于整个微服务框架是灾难性的。为了解决这一问题，ServiceCenter需要有一个自我保护机制（Self-preservation）：13893图8 ServiceCenter的自我保护机制1) ServiceCenter在一个时间窗内监听到etcd有80%的实例下线事件，会立即启动自我保护机制。2) 保护期间内，所有下线事件均保存在待通知队列中。3) 保护期间内，ServiceCenter收到队列中实例上报注册信息则将其从队列中移除，否则当实例租期到期，则推送实例下线通知事件到consumer服务。4) 队列为空，则关闭自我保护机制。有了自我保护机制后，即使etcd存储的数据全部丢失，这种极端场景下，SDK与ServiceCenter之间可在不影响业务的前提下，做到数据自动恢复。虽然这个恢复是有损的，但在这种灾难场景下还能保持业务基本可用。 以上就是ServiceComb的服务管理中心在分布式系统下的高可靠架构设计，在进行大规模、高并发的企业应用开发时，可靠的服务管理中心能够使得分布式系统运行更加稳定，同时高性能的通信也使得分布式系统更高效地处理密集的业务。下篇我们会对ServiceComb高性能通信进行介绍。 华为云微服务引擎 CSE ，截止到2018年6月30日 限时免费立即体验：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home了解详情：https://www.huaweicloud.com/product/cse.html

本帖最后由 大脸猫爱吃鱼 于 2018-4-12 20:37 编辑作者 王齐林 发布于 2018年1月25日 转自InfoQ 近日，ServiceComb开源了该项目旗下的Go语言微服务框架ServiceComb Go-chassis(以下简称Go-chassis)。作为ServiceComb生态中的重要一环，Go-chassis将和已经开源的Apache ServiceComb(incubating) Java-chassis一道，为用户带来良好的框架级多语言微服务编程体验。同时，ServiceComb Go-chassis未来也会和ServiceComb Java-chassis一样，捐献到Apache基金会中。什么是chassis?Chassis，直译成中文是底盘的意思，它是一种微服务模式，由微服务大师Chris Richardson提出。在这种模式中，用户并不需要自己去处理构建微服务过程中外部配置、日志、健康检查、分布式追踪等那些横切关注点（crosscutting concern），而是将他们交给专门的框架来处理。用户可以更聚焦业务逻辑本身，简单、快速的开发微服务。Apache ServiceComb Go-chassis简介Go-chassis是一个用Go语言编写的微服务快速开发框架，采用插件化设计，将各种功能模块定义为接口，实现功能“可插拔”的同时也带来了非常好的扩展性；用户可以定制开发自己的通讯协议、处理链，对接自己的配置中心、服务发现中心等。Go-chassis的模块及工作流程如上图所示，不同协议请求进入到各协议Server，Server将具体的协议请求转换为Invocation统一抽象模型，并传入Handler chain（ 框架内默认内置了大部分微服务治理所需的handler），最终再进入Transport handler，使用具体的协议客户端传输到目标。目前，Go-chassis支持的特性包括但不限于： [*]服务发现（配合ServiceComb现有的ServiceCenter） [*]动态配置管理： [*]负载均衡 [*]流量控制（服务端与客户端） [*]熔断容错 [*]分布式追踪 [*]Metrics [*]日志 [*]路由策略 在通讯协议方面，Go-chassis原生支持REST/Http 和 Highway协议，其中Highway是ServiceComb开发的、基于RPC的高性能通讯协议。使用Go-chassis开发体质指数应用（BMI）下面，我们将以简单的体质指数应用（BMI）为例，说明如何用Go-chassis快速开发微服务。BMI是国际上常用的衡量**胖瘦程度的一个标准，我们开发的BMI应用主要包含两个微服务： [*]体质指数计算器（calculator）：负责处理运算事务。 [*]体质指数界面（web-app）：提供用户界面及网关服务。 两个微服务之间的关系如下图所示，它们之间通过REST方式进行通信。准备工作在开始开发之前，请确保开发环境上已经完成以下配置 [*]安装 git [*]安装 Go 1.8+ [*]安装 docker [*]下载 ServiceComb go-chassis [code]go get https://github.com/ServiceComb/go-chassis[/code] [*]运行 Service Center 在 ServiceComb 微服务框架中，Service Center 提供服务注册及服务发现功能，可直接使用 docker 运行。[code]docker pull servicecomb/service-center docker run -d -p 30100:30100 servicecomb/service-center:latest[/code]体质指数计算器(calculator) 开发体质指数计算器(calculator)提供运算服务，分为具体业务逻辑、服务注册与配置，启动框架三部分： [*]具体业务逻辑 定义服务结构体[code]type CalculateBmi struct { }[/code]编写计算体质指数（BMI）函数，该函数根据公式13847进行实现：[code]func (c *CalculateBmi) BMIIndex(height, weight float64) (float64, error) { if height = 0 || weight = 0 { return 0, fmt.Errorf("Arugments must be above 0") } heightInMeter := height / 100 bmi := weight / (heightInMeter * heightInMeter) return bmi, nil }[/code]​编写handler函数，其中restful.Context必须作为入参传入。restful.Context中包含了对http调用的Request和Response的常用操作，Read开头的为对Request的读取，包括ReadEntity、ReadHeader、ReadPathParameter、ReadBodyParameter、ReadRequest等；而Writer开头的为对Response的写入操作，包括WriteHeader、WriteJson、WriteError等。[code]import ( rf "github.com/ServiceComb/go-chassis/server/restful" ) …… func (c *CalculateBmi) Calculate(b *rf.Context) { …… //定义返回结构体，此处省略 heightStr := b.ReadQueryParameter("height") weightStr := b.ReadQueryParameter("weight") var height, weight, bmi float64 var err error …… //字符串与浮点数类型转换，此处省略 if bmi, err = c.BMIIndex(height, weight); err != nil { errorResponse.Error = err.Error() b.WriteHeaderAndJson(http.StatusBadRequest, errorResponse, "application/json") return } result.Result = bmi result.CallTime = time.Now().String() b.WriteJson(result, "application/json") }[/code]指定对应的URL路由[code]func (c *CalculateBmi) URLPatterns() []rf.Route { return []rf.Route{ {http.MethodGet, "/calculator/bmi", "Calculate"}, } }[/code] [*]服务注册与配置 完成业务逻辑代码的编写之后，需要将业务逻辑注册到Go-chassis框架，注册时可以同时指定微服务的名称、ID等属性。[code]chassis.RegisterSchema("rest",&CalculateBmi{})[/code]除了在代码中指定的部分属性外，更多的属性是通过配置文件来进行配置。配置文件包括chassis.yaml和microservice.yaml，放置于代码目录下的conf文件夹内。其中，chassis.yaml中配置的是微服务的公共属性，如公共的AppId信息，使用的注册中心类型信息、地址信息，服务的协议、监听地址、注册发现地址、传输协议信息等；microservice.yaml配置的是微服务的私有属性，包括服务名、版本等。chassis.yaml[code]APPLICATION_ID: bmi #应用ID cse: service: registry: address: http://127.0.0.1:30100 #注册中心（ServiceCenter）的地址 protocols: rest: listenAddress: 0.0.0.0:8080 #微服务的监听地址[/code]microservice.yaml[code]service_description: name: calculator #微服务名称 version: 0.0.1 #微服务版本号[/code]启动框架和服务[code]import ( "github.com/ServiceComb/go-chassis" "github.com/ServiceComb/go-chassis/core/lager" ) …… if err := chassis.Init(); err != nil { //初始化框架 lager.Logger.Error("init failed", err) return } chassis.Run() //运行微服务[/code]体质指数界面(web-app)开发开发完后端的calculator服务之后，需要开发提供给用户的交互界面，主要分为前端静态界面、请求转发、服务启动入口三个部分。 [*]前端静态界面 前端静态界面使用了Bootstrap开发，并通过golang 官方库中http.ServeFile将前端静态页面展示出来。[code]func BmiPageHandler(w http.ResponseWriter, r *http.Request) { http.ServeFile(w,r,"external/index.html") }[/code]请求转发体质指数界面（web-app）微服务收到前端界面发过来的请求时，通过core.NewRestInvoker()将请求转发到calculator服务。在转发调用的过程中，用户并不需要感知calculator服务具体的地址和端口，服务发现的过程由go-chassis框架自动完成。[code]func BmiRequestHandler(w http.ResponseWriter, r *http.Request) { queries := r.URL.Query() heightStr := queries.Get("height") weightStr := queries.Get("weight") requestURI := fmt.Sprintf("cse://calculator/bmi?height=%s&weight=%s", heightStr, weightStr) restInvoker := core.NewRestInvoker() req, _ := rest.NewRequest("GET", requestURI) resp, _ := restInvoker.ContextDo(context.TODO(), req) w.Header().Set("content-type", "application/json") w.WriteHeader(resp.GetStatusCode()) w.Write(resp.ReadBody()) }[/code] [*]服务配置与启动 体质指数界面（web-app）服务的配置文件同样包括chassis.yaml和microservice.yaml两个yaml文件，具体内容如下：chassis.yaml[code]APPLICATION_ID: bmi #应用ID cse: service: registry: address: http://127.0.0.1:30100 #注册中心（ServiceCenter）的地址[/code]microservice.yaml[code]service_description: name: web-app #微服务名称 version: 0.0.1 #微服务版本号[/code]与calculator服务不同，体质指数界面（web-app）在Go-chassis框架内是一个消费者类型的服务，故只需调用chassis.Init()对Go-chassis框架进行初始化。[code]func main() { http.HandleFunc("/", BmiPageHandler) http.HandleFunc("/calculator/bmi", BmiRequestHandler) if err := chassis.Init(); err != nil { lager.Logger.Error("Init fail", err) return } port := flag.String("port", "8889", "Port web-app will listen") address := flag.String("address", "0.0.0.0", "Address web-app will listen") fullAddress := fmt.Sprintf("%s:%s", *address, *port) http.ListenAndServe(fullAddress, nil) }[/code]界面效果通过上述步骤，体质指数（BMI）应用已经开发完毕，可以通过http://localhost:8889访问该应用，届时将能看到如下界面，并可输入身高和体重信息验证服务是否正常运行。使用Go-chassis进行微服务治理除了基础的业务逻辑开发外，Go-chassis提供了丰富的微服务治理功能。下面将在刚刚开发的体质指数应用（BMI）基础上，介绍如何使用Go-chassis进行微服务治理。负载均衡当对体质指数计算器（calculator）进行水平扩展时，需要将请求均衡地分发到多个体质指数计算器（calculator）上。Go-chassis的负载均衡功能包括负载均衡策略和负载均衡过滤器两种方式。微服务实例在经过过滤器中制定的规则初筛之后，根据策略算法选出一个合适的实例进行下一步处理。Go-chassis内置了RoundRobin，Random，SessionStickiness，WeightedResponse四种策略，其中默认使用的策略为RoundRobin。此外，无论是负载均衡策略还是负载均衡过滤器，开发者都可以根据自己的需求进行定制。 [*]开启 负载均衡功能默认开启，不需要另外配置。若用户希望使用RoundRobin之外的策略，可以在配置文件chassis.yaml中进行指定。[code]cse: loadbalance: # 全局负载均衡配置 strategy: name: Random microserviceA: # 微服务级别的负载均衡配置 strategy: name: SessionStickiness[/code]对体质指数计算器（calculator）进行水平拓展时，用户只需复制原有代码，并在配置文件中修改监听端口，使得新的实例在另一个端口运行即可。 [*]微服务实例的本地缓存 为了便于区分不同的运行实例，在体质指数计算器（calculator）的实现中新增了返回实例ID的代码。[code]import ( "github.com/ServiceComb/go-chassis/core/registry" ) …… items := registry.SelfInstancesCache.Items() for microServiceID, _ := range items { instanceID, exist := registry.SelfInstancesCache.Get(microServiceID) if exist { result.InstanceId = instanceID.([]string)[0] } }[/code]Go-chassis框架初始化时，会将注册中心中的实例缓存到本地，并每30秒同步一次注册中心和本地缓存的数据（可配置）。代码中使用了本地缓存的数据来获取实例ID。 [*]验证 上述操作完成后，在界面上点击Submit 按钮，可以发现实例ID交替变换。流量控制 [*]开启 流量控制机制通过控制数据传输速率来避免微服务过载运行。用户可以进行服务端流量控制，限制接收处理请求的频率，在体质指数计算器（calulator）的chassis.yaml中可进行服务端流量控制的配置：[code]cse: handler: chain: Provider: default: ratelimiter-provider #添加服务段流量控制的handler flowcontrol: Provider: qps: enabled: true # 是否启用流量控制 limit: web-app: 1 # key为指定要限制的微服务调用者名称，此处web-app为调用calculator的微服务的名称；value为每秒允许的请求数。[/code]也可以进行消费端流量控制，限制发往指定微服务的请求的频率。在体质指数界面（web-app）中的chassis.yaml中配置：[code]cse: handler: chain: Consumer: default: ratelimiter-consumer #添加消费者段流量控制的handler flowcontrol: Consumer qps: enabled: true # 是否启用流量控制 limit: calculator: 1 # key为指定要限制的请求发往的微服务的名称；value为每秒允许的请求数[/code]验证访问 http://localhost:8889，在身高和体重的输入框中输入正数，尝试在1秒内多次点击 Submit 按钮。此时，能看到所有的请求将被后台延迟处理，处理的频率为1次/秒。熔断与降级 [*]开启 熔断与降级主要用于解决或缓解服务雪崩的情况，即个别微服务表现异常时，系统能对其进行处理，从而避免资源的耗尽。用户可以在服务端体质指数计算器（calculator）的chassis.yaml 文件中指明使用服务治理的处理链及指定熔断和容错策略：[code]cse: handler: chain: Provider: default: bizkeeper-provider circuitBreaker: Provider: calculator: requestVolumeThreshold: 3 #10s内发生错误的阈值，超出阈值触发熔断 fallback: Provider: enabled: true fallbackpolicy: Provider: policy: returnnull #出错后的处理策略[/code] [*]验证 [*]使服务进入熔断状态。访问 http://localhost:8889，在身高或体重的输入框中输入一个负数，连续点击三次或以上 Submit 按钮，此时在网页下方能看到类似左图的界面。 [*]验证服务处于熔断状态。在身高和体重的输入框中输入正数，再次点击 Submit 按钮，此时看到的界面依然是类似左图的界面。同时在 体质指数计算器(calculator) 后台运行日志中也能看到 circuit open 的日志。 [*]验证服务恢复正常。约5秒后 ，在身高和体重的输入框中输入正数，点击 Submit 按钮，此时界面显示正常。 分布式调用链追踪开启分布式调用链追踪用于有效地监控微服务的网络延时并可视化微服务中的数据流转。启用分布式调用链追踪，需要在体质指数计算器（calculator） 的 chassis.yaml 文件中添加如下配置，指定追踪数据上报的开关以及上报地址、上报类型等。[code]cse: handler: chain: Provider: default: tracing-provider tracing: enabled: true collectorType: zipkin collectorTarget: http://localhost:9411/api/v1/spans[/code]同样的，在体质指数界面（web-app）中的chassis.yaml中进行如下配置：[code]cse: handler: chain: Provider: default: tracing-consumer tracing: enabled: true collectorType: zipkin collectorTarget: http://localhost:9411/api/v1/spans[/code]此外，还需要运行Zipkin 分布式追踪服务，可以采取Docker方式：[code]docker pull openzipkin/zipkin docker run -d -p 9411:9411 openzipkin/zipkin[/code]验证首先访问 http://localhost:8889 ，在身高和体重栏处输入正数，并点击 Submit 按钮。然后访问 http://localhost:9411 ，进入Zipkin查看分布式调用追踪情况，可得下方界面。​Metrics [*]开启 监控数据能直观的显示微服务应用的性能数据，帮助更好的进行微服务治理、制定弹性伸缩策略等。Go-chassis支持输出Prometheus格式的监控数据，提供的数据包括Golang运行时的数据、微服务进程的内存占用、CPU占用情况等。要使用监控功能，需要在体质指数计算器（calculator） 的chassis.yaml 文件中添加下列内容：[code]cse: metrics: apiPath: /metrics enable: true enableGoRuntimeMetrics: true #是否开启go runtime检测 [/code] [*]​​​​验证 首先访问 http://localhost:8889 ，在身高和体重栏处输入正数，并点击 Submit 按钮。然后访问 http://localhost:8080/metrics（其中8080为体质指数计算器（calculator）服务端监听的端口），可以得到下图所示的监控数据：加入ServiceComb社区​ 本文介绍了ServiceComb Go-chassis的基本特性以及如何使用ServiceComb Go-chassis开发体质指数应用（BMI）以及进行微服务治理。整个示例的源代码可以从Github上获取。同时，作为一个新开源的项目，ServiceComb Go-chassis诚挚的欢迎大家一起参与社区讨论，贡献代码，共同努力打造“最好用的Go语言微服务框架”。 [*]ServiceComb Go-chassis github地址：https://github.com/ServiceComb/go-chassis [*]ServiceComb官方网站：http://servicecomb.incubator.apache.org/ [*]ServiceComb邮件列表：[email]dev-subscribe@servicecomb.incubator.apache.org[/email]

作者介绍：田晓亮，8年软件行业经验，曾就职于三星，2012年进入云计算领域，对PaaS，DevOps，APM有深入的研究和实践经验，方案支撑近千台VM中的应用部署监控。 2016年加入华为担任架构师，负责微服务的Go语言开发框架及Service Mesh设计和落地，Go语言微服务框架已被华为5G核心网络采用，Service Mesh服务也已在华为云商用上线。 微服务架构是个难题，但解法有多个微服务是一个很大的概念，从团队组织到最佳实践似乎都有实施微服务的一些指导。我们这里只提构建微服务的架构模式，也就是关乎到你用什么样的方式来构建你以微服务架构来组织的应用系统。近些年随着微服务的火热，越来越多的团队开始进行实践，将微服务纷纷落地，也许你是从0开始，一步步地完成了单体应用向微服务的改造，让我们来看看，你解决了多少问题。 13830图1 微服务架构需要解决的问题 微服务将原本内存中函数的调用转换为网络中的调用后，就牵扯到这些问题，而任何一个分支展开，都会涉及一系列的问题。业务开发者也许真的有精力去学习架构相关的复杂问题，然而对于公司来说，真正有价值的是业务本身，让业务开发者解决这些问题需要花费浪费大量的时间精力，导致业务上线受到影响。那我们来看看是否有便捷的方式来解决业务开发者的痛点。Chassis模式 一句话来概括：一种语言开发框架来作为微服务开发的底座，封装掉复杂性，帮助你解决跨网络带来的问题，让用户聚焦在上层业务逻辑的开发。通常情况下会实现以下功能： [*]日志、Metrics、分布式追踪数据上报 [*]健康检查 [*]对接统一的配置中心实现动态配置 [*]对接注册中心 [*]实现负载均衡、熔断降级、容错、限流等保证高可靠运行的功能 现在我们来看看业界有哪些可用的Chassis框架 [*]Spring Cloud [*]ServiceComb [*]Dubbo [*]Go-Micro [*]Go-Kit 先不细去纠结微服务的严格定义，也先暂且搁置诸如“某些老旧框架是否是真的微服务框架”这类争议，从实现方式来看，上述服务化框架都是将分布式系统开发的复杂性进行了一定程度的封装然后提供了简便的开发接口供使用者调用。但是，用这种方式构建微服务还有一些问题： [*]多语言SDK支持：微服务提倡不同组件使用最适合它的语言开发，但是这需要每种语言都有开发框架，不断实现相同的功能。上面可以看到只有go语言和Java语言出现了微服务开发框架，其他语言呢？ [*]不论代码侵入程度，都需要开发者思考如何与SDK结合，并从代码层面做出改变，对于大部分开发者来说都是一个高曲线的学习过程。 [*]绑定了特定技术栈，一旦想抽身就需要一定程度上的代码改造。 [*]老旧单体应用由于无人维护，耦合程度高等问题无法进行改造，在进行微服务拆分的过程中重用遗留代码变得无比困难。而且微服务的拆分难以分步进行，需要一个相对较长的周期将系统整体拆分后才能上线。 我们知道技术演进来自于在实践中不断地将功能抽象，解耦，封装，服务化。 [*]云计算技术出现前是数据中心虚拟化，不断地实践使技术发展形成理论和新的实践。IaaS是一种封装，如今开发者与大部分技术团队不需要再学习虚拟化等技术以及如何维护数据中心。 [*]没有TCP/IP的时代，开发人员需要自己考虑网络间数据包的传输，以及网络传输代码与业务代码完全耦合的问题，如今，开发者已经不需要关心，操作系统和开发语言已经封装好网络传输过程。 是否也可以把语言框架提供的能力抽象，成为服务？ 在引入后面内容前，我先介绍下SideCar模式SideCar模式 [*]在近些年受到Kubernetes对容器调度方式的启示而日渐受到关注的一种功能部署模式，也是一种微服务的设计模式。 [*]主要利用了一个Pod中的容器可以共享存储与网络的能力，或者说在一个Host中，这个模式也同样适用。 [*]一般分为应用容器和工具容器，工具容器可以重用。 一个典型的场景如下: 13831图2 SideCar典型场景 应用容器与日志同步工具在同一个Pod下，共享存储卷，应用程序生成的日志文件会由日志同步工具收集并发送到类似kafka，elasticsearch这样服务中。在这样的架构下我们获得了什么呢？ [*]以容器作为基础打包单元，那么就可以分给不同的团队进行开发测试 [*]Sidecar容器可重用，可以与不同的容器结合 [*]以容器作为错误边界，使服务能够独立开发和测试，比如应用服务在没有日志保存功能的情况下也可以独立运行 [*]独立回滚与更新（但需要考虑复杂的版本组合，建议使用语义版本管理对版本进行控制） 在这个模式的基础之下，我们引入了Service mesh。Service Mesh 新瓶中的那一杯老酒什么是Service Mesh Service mesh最早是由Linkerd给出的定义，我们来看看英文版:[indent]A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.[/indent]大致的意思如下： [*]一种基础设施层服务，服务间的通信通过service mesh进行 [*]可靠地传输复杂拓扑中服务的请求，将它们变成现代的云原生服务 [*]一种网络代理的实现，通常与业务服务部署在一起，业务服务不感知 [*]一种网络模型，在TCP/IP之上的抽象层，TCP/IP负责将字节码可靠地在网络节点间传递，Service mesh则复杂将服务间的协议请求可靠地在服务间进行传输。它们不关心传输的内容 [*]TCP/IP仅仅负责传输，但Service mesh可对运行时进行控制，使服务变得可监控，可管理。 为什么使用Service Mesh [*]无需考虑每种语言都要解决的问题 [*]对业务代码0侵入，开发者无需关心分布式架构带来的复杂性以及引入的技术问题 [*]对于不适合改造的老旧单体应用，提供了一种接入分布式环境的方式 [*]微服务化的进程通常不是一蹴而就的，很多应用选择了演进的方式，就是将单体应用一部分一部分地进行拆分。而在这个过程中，使用Service Mesh就可以很好地保证未拆分的应用与已经拆分出来的微服务之间的互通和统一治理 [*]开发出的应用既是云原生的又具有云独立性，不将业务代码与任何框架，平台或者服务绑定 依然没有银弹，我们来看看Service mesh解决不了的问题 [*]无分布式事务方案 [*]Service Mesh组件代理请求转发，会在一定程度上降低系统通信性能 [*]没有Event Driven的框架 [*]侵入式框架以源码和业务代码结合，有较强定制和扩展能力，Service mesh相对不易定制扩展 [*]在运行时，依赖单独的Service Mesh代理，多了一个故障点。整个系统的运行和运维也强依赖于Service Mesh组件的能力 Service Mesh的实践历程和设计思路Service Mesh在华为公司内部的发展历程 第一代： 基于NGINX的微服务代理该平台是华为公司内部使用的微服务开发部署运行平台，开发于2013年，用于公司内部某电信业务。在这个业务系统中有大概400多个左右的微服务，实例数量根据局点大小不一样，一个典型的部署为800多个左右实例的规模。整体架构如下：13832图3基于NGINX的微服务代理的平台整体架构 其中的Internal Router组件用来给开发者解决分布式架构中的可靠传输问题： [*]使用高性能nginx及其相应的lua扩展作为Internal Router，将Http服务接入 [*]使用RouteAgent负责注册/注销实例，更新IR的实例信息 [*]使用zookeeper作为注册中心 [*]以Per-Host的方式部署在微服务所运行的环境中 用这种方式构建的微服务环境已经在超过200个局点的生产环境下得到使用，整体运行情况良好。但是随着时间的推移，当业务对敏捷的要求越来越大，而且容器的使用也越来越广泛，这种方式带来了一些问题： [*]使用lua脚本扩展注册发现，负载均衡，熔断，降级，容错，限流，但lua的扩展性有一定的局限 [*]用RouteAgent负责服务的注册以及每个NGINX上服务实例路由的刷新，RA需清楚地感知本节点上的微服务都有哪些，但是使用Kubernetes做容器调度后微服务和实例的分布信息在K8S里面集中记录 [*]容器的IP更多，变化更频繁，使用RouteAgent刷新NGINX路由的方式会导致NGINX服务受到影响，频繁的路由刷新导致业务运行收到影响 [*]当IR服务失败后，整个Host中的服务都会丢失，无法与外界建立联系 为了解决这些问题，出现了第二代的解决方案： HSA Sidecar13833图4 HSA Sidecar设计 HSA是华为内部的一套微服务开发框架，它提供了注册中心，配置中心，java开发框架，以及SideCar等组件 [*]基于Java 微服务框架开发,非侵入式通信方式，支持RPC与Http，提供SOAP协议转换，但会导致性能下降 [*]与微服务部署在一个Pod中即Sidecar模式 [*]作为代理服务，使微服务自动获得注册发现，负载均衡，熔断，降级，容错限流等功能 [*]占用资源很高，一个应用实例一个Sidecar实例的部署方式，会占用过高资源 虽然第一代的问题解决了，但是第二代的Sidecar在性能和资源占用上有很大的问题，在少量的技术项目中试用后，因为资源占用过高的问题无法在大规模环境中推广使用。CSE Mesher介绍 Service Mesh 模式的一种实现。基于自研的Go语言微服务框架（该框架即将开源）开发，使用ServiceComb注册中心（已经开源）与CSE配置中心，以Sidecar的方式部署在微服务所运行的环境中，也可以PerHost模式运行。在用户数据面使用，提供VM部署、公有云部署、容器部署，占用资源小（闲置10多M，并发运行时30多M）。基本能力 注册发现注册中心为插件化模块，目前对接了ServiceComb、Service Center，未来还会有更多的系统对接进来 13834图5 可插件化的注册中心 路由规则管理根据预定义的路由规则对请求进行引流 [*]支持权重引流：比如将5%的流量引到购物车的1.0版本，20%引到2.0版本 [*]可根据服务请求特征进行引流：比如消费者的请求中Header带有的用户名为Json，那么可以引流到某个服务的特定版本中 [*]利用读写锁，路由可在运行时更新，并且不丢失请求 协议转换与不同框架的对接与统一治理使用标准OpenAPI契约，可以实现Dubbo RPC协议与Http协议的互转，用于透明地接入遗留的Dubbo应用并对遗留应用进行统一的服务治理使用负载均衡与重试策略 [*]负载均衡器会调用注册中心插件进行实例查询 [*]在查询中的实例里表中，使用Filter进行过滤 [*]将过滤后的实例传入Strategy中进行实例选择 [*]默认提供RoundRobin Random，会话粘滞策略 [*]具备容错能力且加入Backoff算法，增强网络稳定性 使用熔断降级熔断使用的断路器对一个执行过程进行包装，断路器负责监控维护每个执行过程的状态、结果、错误、超时。当达到一定阀值时就会熔断，并触发降级。以这样的机制来保护服务提供者，不会出现级联的雪崩式错误。使用限流提供了消费者端与提供者端限流用户可以通过配置来限制每秒只允许多少个请求被发出或者接受对接监控Metrics：提供了主动上报到CSE Dashborad的方式。也可与华为公有云APM，Prometeus对接 分布式追踪：对接Zipkin架构设计 整体架构13835图6 CSE Mesher整体架构 Mesher背靠CSE组件，使用微服务引擎中的服务中心与配置中心等服务作为控制面，Mesher与业务代码部署在一起运行在数据面数据面13836图7 CSE Mesher数据面 即Service mesh组件本身，对所有请求进行处理，它有以下功能 [*]发现服务 [*]执行路由策略 [*]负载均衡 [*]拦截所有请求并处理，转发 [*]认证鉴权 [*]生成监控数据 控制面13837图8 CSE Mesher控制面 为管理人员提供统一的管理入口，为所有运行的mesher提供配置下发但不会介入服务请求 [*]注册中心：服务上下线感知 [*]下发配置：使用Web Console对运行时更改，负载均衡，熔断容错，限流等策略 [*]对接监控服务与监控页面 [*]调度引擎：这里并非是微服务引擎提供的组件，是可选组件，这个组件负责拉起服务，维护实例数，在资源池中调度分配实例，这里推荐使用ServiceStage负责实例的生命周期管理 运行场景 不同的部署方式与业务服务部署在一起有3种运行模式1.仅消费者使用Mesher，提供者为使用ServiceComb开发框架的服务或者裸服务，下图为例:ServiceC为裸服务,它既不用mesher也不用SDK，那么起码它需要自己注册到服务中心中，供其它服务发现，否则无法进行访问。13838图9 仅消费者使用Mesher 2.消费者与提供者均使用Mesher13839图10 消费者与提供者均使用Mesher 以这种方式运行的服务可以使用透明TLS传输，并且拥有了服务端限流3.提供者使用Mesher，消费者A使用ServiceComb SDK进行开发可直接发现服务B，但是消费者C作为裸服务需要自己发现服务B 13840图11 仅提供者使用Mesher 运行时请求处理消费者端请求 13841图12 消费端发送请求流程 上图为例：SockShop服务将mesher作为代理并使用地址http://order/list访问订单服务 [*]Destination Resolver 目标微服务名解析，支持插件定制，可根据请求特征决定微服务名是什么 [*]Source Resolver 将IP地址解析为微服务实体信息 [*]路由决策 根据Source和Destination 信息决定最终要访问哪个微服务 [*]处理链 处理链为可随时**或减少的模块，在这里Mesher实现了限流，熔断，降级，负载均衡等功能 [*]传输层 最终请求通过传输层发送到目标微服务实例 提供者端接收请求 13842图13 提供者端接收请求流程 上图为收到远程请求后的处理过程 [*]服务端接到请求，将IP地址解析为微服务信息 [*]进入处理链，这一步并没有负载均衡而是直接使用local selection 进行处理 性能对比 13843图14 Mesher1.0、Istio 0.1.6 (Envoy)、Linkerd1.1.3性能对比 在性能对比后，我聊下自己的看法 [*]Linkerd 作为java实现的service mesh，受到资源占用的拖累，考虑到数据中心成本，不适合作为SideCar和应用部署在一起，相信它的主要场景在于Kubernetes Ingress和Daemonset，并且由于只有数据面，需要和别的生态系统对接获得控制面能力，否则，业务团队又要考虑自己开发控制面。 [*]目前Istio已知问题是每次请求都要调用一次Mixer API来传送metric数据，相信未来版本能够解决，但不能满足我们内部的产品节奏。 [*]作为对比，Mesher通过Channel与Go协程机制主动上报metric数据，以此获得更高的性能，机制如下：模块将数据传送到channel中，协程收到信号并主动上报，在这样的机制下开启监控，性能只有百分之2左右的下降。 13844图15 Metric数据上报机制 一些思考以及未来华为为什么开发了自己的Service Mesh [*]Istio的性能问题没有解决，Envoy每次访问请求Mixer API导致性能下降 [*]Istio强绑定Kubernetes平台（1.7.4+），虽然有着良好的架构，对接不同平台不是问题但需要时间，Mesher贯彻不将开发者绑定到任何框架和平台的理念 [*]从成本角度讲Linkerd并不适合做SideCar部署，JVM资源占用较多 [*]过去在ServiceComb中的积累：Service center，Config center，Go SDK，Governance UX已经提供了大量技术积累，可用于做Mesher的控制面。 [*]既然非侵入式与侵入式都不是银弹，侵入式（ServiceComb Java）与Mesher提供的非侵入式框架的无缝结合，混编就变得有价值了，开发者可以因地制宜，选择适合自己的方案。 Service Mesh是个大舞台 现在已经出现了越来越多的Service mesh实现： [*]数据面：Linkerd，Nginx，Envoy [*]控制面：Istio Linkerd 是在2016年出现的，Envoy在6个月后出现，不过Envoy已经在2015年就商用了。这两个项目也是最有名的Service Mesh。Istio在2017年5月出现，它提供了控制面，并使用Envoy作为数据面的Service Mesh。目前已经开始有些Service Mesh提供者宣布与Istio进行集成，比如Linkerd和Nginx。这意味着控制面与数据面是解耦的，任何的控制面都可以和数据面Service Mesh进行集成。CSE Mesher也会考虑与Istio进行集成，成为除了Envoy之外的另一种数据面选择。实际上在开源项目之外，很多公司内部也早已用类似的方案进行自己系统的构建，各自有各自的特点用来解决自己的实际问题。Istio成为CNCF里面一个被认为是“Kubernetes之后的第二个爆款”是有理由的，它提供了一种从平台的角度解决应用架构的思路，进一步简化了应用的开发。我们也相信在这个大舞台上会有更多的方案出现，而这些方案的出现也会让微服务和Cloud Native应用的构建方式有更多地选择。我们团队也已经基于多年的实践经验将当前的内部Service Mesh方案包含在华为云的“微服务引擎”中，开放给外部用户使用。希望可以作为一种参考，可以给正在选择实施微服务架构方案的读者一些帮助。

本帖最后由 橘色祥云楼楼主 于 2018-3-27 09:35 编辑13272 2018华为合作伙伴大会在青岛落下帷幕，在备受企业关注的云计算领域，华为云现场正式发布了云容器实例CCI（无服务器容器）、CCE-Windows容器、微服务引擎CSE-Mesher、区块链服务BCS四款业界领先的云上应用服务，专注解决企业在云上开发运维中遇到的瓶颈和难题，帮助企业应用快速上云，加速业务创新，从容面对数字时代的转型和挑战。 ↓↓↓ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 【Cloud 1.0时代，用户主要关注基础设施云化，华为在基础设施虚拟化方面，一直拥有持续领先的技术优势。Cloud2.0时代，企业更加关注应用上云，期待应用的高效迁移部署和快速迭代开发。基于华为长期以来在容器与微服务领域的技术与实践积累，华为云向用户提供容器和微服务等以应用为中心的云服务，使能企业应用上云更加简单、运行更高效。— 华为云BU总裁郑叶来】~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13266云容器实例CCI 全球首款基于Kubernetes的无服务容器 在容器运用日趋普及的当下，利用容器来提升资源利用率、优化算力、简化运维已成了企业云上开发与运维的共识。云容器实例CCI则是全球首款基于Kubernetes的无服务器容器，为企业及开发者提供无服务器化的运行时全托管，无需管理集群和服务器即可在CCI上快速创建和运行容器负载，解放繁杂的运维管理，聚焦核心业务从根本上简化了容器的使用方式，将容器服务“量体瘦身”，为企业提供Serverless化全新一代的体验和选择。华为云的容器服务源于在Kubernetes社区上的长期积累和实践（K8S社区国内贡献度第一），而CCI的发布则是一举奠定了华为在Kubernetes生态中的领先地位。13267微服务引擎CSE-Mesher 首家商业落地实现零侵入式分布式改造 自去年Service Mesh概念（又称网格服务）横空出世后，华为云基于现有的微服务引擎CSE自主研发了首款商用落地的Service Mesh服务——微服务引擎CSE-Mesher。Mesher作为处理服务间通信的基础设施层，解决了传统分布式系统云化架构中的复杂通讯难题，并不再以单一语言绑定，帮助企业现有单体应用零改造快速平滑上云。相比开源的Istio可提供超过十倍性能的体验，此外商用的可靠支撑，打消了用户对开源易用性不足的顾虑。 微服务引擎CSE自去年上线以来，便成功运用在华为手机——智能助手的亿级用户场景中，半年时间里已联合数十家合作伙伴打造了众多企业级微服务解决方案。 13268云容器引擎CCE-Windows容器 打破Linux一统天下格局 即去年国内首发用于高性能计算场景的裸金属容器特性后，云容器引擎CCE本次又全新发布了其Windows容器特性，支持基于Windows Server系统的容器服务，使此前只能在Linux系统上部署容器的尴尬成为了历史，这意味着大量如基于.NET开发的应用可借助Windows容器能力轻松实现容器化，帮助其提升云上运行效率，减少资源消耗，尽享容器化带来的便捷，焕发系统第二春。 在本次大会，华为云与管家婆云科技有限公司联手发布了Windows容器实践解决方案，华为云Bu服务产品部部长廖振钦在产品发布环节分享了Windows容器的研发历程，而管家婆CEO宁洪先生现场向与会嘉宾分享了基于华为云Windows容器技术的应用云化实践改造经验。 13269区块链服务BCS使能社会诚信助力企业一键“上链” 会上，华为云正式对外宣布开放了此前还在邀测阶段的区块链服务BCS（Blockchain Service)，并联合车车科技发布了基于BCS区块链技术的互助社群区块链解决方案，在3月30号后，用户可在官网自行体验使用。 BCS面向企业及开发者提供高性能、高可用、高安全的公有云区块链服务，可帮助企业及开发者在华为云上快速、低成本的创建、部署和管理区块链应用。华为云区块链服务BCS是基于华为在分布式并行计算、容器、数据管理、安全加密等核心技术领域多年积累上研发的云服务产品，企业最快可以五分钟完成区块链技术的部署，一键快速“上链”更加专注自身业务场景，无须再让技术限制自身业务的想象力与发展。车车科技基于华为云的区块链服务，一个月内完成了互助社群的新应用上线。车车科技的CEO张磊现场亲自分享了基于BCS的社群应用实践心得。 13270 本次的产品发布，充分展示了华为云在容器、微服务等Cloud-Native新一代技术上的领先优势。并通过与合作伙伴及客户的联合创新，不断推进容器、微服务、区块链等技术的成熟及落地，聚焦为用户提供敏捷、高效、可靠、企业级的应用云化解决方案，让企业上云更简单，云上运行更高效。

本帖最后由 橘色祥云楼楼主 于 2018-6-5 15:57 编辑序：华为智能助手是华为在手机终端中推出的智能应用服务，在手机负一屏中聚合用户所需要的内容与服务，并结合用户的习惯与喜好进行智能推荐。用户只需在首屏轻轻一划，不用打开各类繁琐的手机应用，即可直接获取想要的服务与内容，帮助用户的工作生活更加智能和便捷。 随着智能手机的日益普及，手机中的智能应用正在走进人们生活中的每一个角落，作为运行在华为手机上的超级应用，华为智能助手以3.2亿的用户体量运行在华为云的终端云上，为用户提供稳定可靠的智能生活服务，其中应用市场日活高达6500万，云端相册每日新增相片已达4200万，庞大的体量使得应用系统稳定、可靠、敏捷的运行显得至关重要，而在背后全天候高效支撑的正是华为云PaaS服务中的微服务引擎CSE(CloudService Engine)。 11807 CSE是华为云PaaS家族产品中的企业架构解决方案，可为企业提供高性能的微服务框架和一站式的服务注册、服务治理、动态配置和分布式事务管理，帮助传统架构真正实现微服务应用的快速开发和高可用运维，而自去年商用发布以来便全面应用在华为智能助手的传统架构改造中。 从月到天 助力亿级应用交付周期大幅缩短 华为智能助手可以根据用户的使用习惯提供个性化的应用推荐组合，同时也为用户提供了应用市场、游戏中心、智能家居、视频、阅读等多种基本工具应用，满足用户生活中的各种智能化场景，随着业务量与日俱增，在海量用户的数字化场景下，早期的单体应用架构已不能满足业务的高并发、敏捷迭代的业务需求，迭代上新节奏缓慢，牵一发动全身，不仅仅影响用户体验，更严重影响了云端的运维效率，系统架构向分布式云化架构发展已成必然。 CSE具备开发模式门槛低、通用性强的改造优势，并支持契约优先，服务接口统一规范管理，微服务之间的调用非常方便，根据业务的现实痛点，智能助手将其后端拆分为多个微服务，并实施集群部署，而这一切全部基于CSE微服务框架开发并统一管理，现已支撑9000万用户日均1.8亿次请求，CSE稳定支持华为智能助手实现多个应用的分布式部署及管理，大幅缩短应用的迭代周期，并通过动态自治帮助其释放运维成本。 11804 以智能助手中的华为音乐为例，华为云CSE将其拆分为运营管理、内容推荐、用户交互三大服务场景，并进行了十五个以上的微服务拆分，使每个应用实现分布式的独立并行，新特性功能上线时间从以往的月为单位提升至天，大大缩短了业务的交付周期，通过敏捷迭代，不断满足在消费者场景中多变突发的需求。 化繁为简 实现复杂运维场景的自动化管理 虽然智能助手务已经跑在云端，在此前的单体架构的支撑下已难跟上前台业务的节奏，随着业务量的爆发性增长，服务越来越多，如何协调线上运行的各个服务，保障服务的SLA，对服务架构和运维人员是一个很大的挑战，当线上业务发生故障时，需要对故障业务做服务降级、流量控制、流量迁移等，快速恢复业务，这使运维的成本和难度成几何级上升。 11805 CSE通过在线的微服务治理，帮助智能助手实现微服务的弹性伸缩、故障自动迁移、降级熔断等，保障系统的运行质量。采用CSE微服务进行改造，使华为智能助手的运维效率大幅提升，智能助手应用SLA从99.9%提升到99.96%，有效的释放了沉重的运维压力。针对更轻量级的架构，智能助手的技术团队同时也拆分至多个3-5人的微服务团队，负责整个微服务的设计、开发、测试、部署运维和治理，通过全功能团队的建设，让业务真正敏捷起来。 有序重构 同等配置架构性能有效提升50% 早期的智能助手以部门自研GAF（封装Redis+Zookeeper作为通讯中间件）框架基础上构建，在并不复杂的业务场景下可以满足系统的稳定运行，随着业务量的攀升、系统复杂度提升、应用场景不断增加，GAF的架构开发门槛高、系统可扩展性差、应用耦合性高的问题日益严重，无法应对高并发流量场景，系统演进迫在眉睫。 11806 使用CSE框架进行全部重构之后，所有系统拆分成微服务，微服务之间调用采用Restful接口，使用SpringMVC的开发风格，开发效率提高一倍。使用EdgeService统一接口接入、鉴权、流控，在接口兼容场景前提下，同样的资源配置，系统吞吐量提高50%，系统开销降低30%。系统在可扩展性、高可靠性上优势明显，新特性开发全面采用DevOps开发模式，开发、运维成本明显降低。 华为消费者云微服务化总架构师王世军：随着华为终端消费市场的不断扩大，用户服务以及用户体验的持续提升显得尤为重要。作为距离桌面主屏最近的区域，华为智能助手在手机负一屏上不断的实现技术与产品创新，借助华为云CSE的微服务框架进行分布式云化改造，在提升系统性能，降低运维成本的同时，可以让智能助手更加专注在应用服务层的创新，持续为三亿用户提供更“懂”你的智能生活服务。 华为云PaaS服务产品部部长廖振钦表示：微服务与容器技术的结合正在发挥越来越重要的作用，华为“全面云化”战略下的统一PaaS平台，微服务与容器是其核心技术。华为微服务CSE已经在华为流程IT、各产品线云化、消费者云、外部客户等众多重大项目上成功稳定商用。包括最近在世界移动大会MWC2018上发布的华为5G核心网解决方案，也是基于华为的微服务架构。我们欢迎更多企业用户使用华为云的微服务，助力企业应用上云更简单、运行更高效，实现Cloud-Native敏捷开发。 CSE以华为自身实践为基础，历经亿级消费者业务场景的考验，专注帮助企业解决云化转型及上云前后的分布式架构改造难题，针对不同企业的业务场景，提供多语言、多架构的解决方案，致力于帮助企业搭建自身的分布式系统，更加敏捷的应对数字化转型带来的挑战。华为云微服务引擎 CSE ，截止到2018年6月30日 限时免费立即体验：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home了解详情：https://www.huaweicloud.com/product/cse.html

在微服务连接注册中心时微服务报错： 2018-02-01 01:59:59 WARN i.s.s.c.h.ServiceRegistryClientImpl - {"errorCode":"401002","errorMessage":"Request unauthorized","detail":"Get service token from iam proxy failed,{\"error\":\"get project token from iam failed. error:http post failed, statuscode: 400\"}"} 此时建议用户检查微服务microservice.yaml当中配置的AK/SK是否和本账号当中的凭证一致： AK/SK如何添加请参考： 开发指南地址：http://static.huaweicloud.com/up ... 103110250_49289.pdf 章节：1.7.2 AK/SK 加密存储 AK/SK如何生成： 我的凭证访问地址：https://console.huaweicloud.com/iam/#/myCredential

华为的微服务框架当前有两个版本，其中开源版本名字叫ServiceComb，已经捐献给Apache社区并已经进入Apache孵化器，另外商业版本名字叫CSE（Cloud Service Engine）注：商业版本由于版权原因不能与开源同名。后面都以框架来统称。 框架从设计之初就是希望做到支持当前Clo**ative趋势下降低各企业业务微服务化门槛的目标，综合了当前业界主流开发框架的有点和场景，是一个多语言(Java&GO)的高性能的开发框架，同时提供了当前非常热门的ServiceMesher能力，同时，设计时就考虑到对当前热门框架的延续性，支持SpringCloud/dubbo等应用零修改接入。所以，不论是传统的行业，还是金融、互联网、物联网、医疗等各行各业都可以使用这个框架实现业务服务化。更加深入的信息，可以到商业介绍和开源社区去做深入了解： 商业介绍： 微服务引擎www.huaweicloud.com 与业界其他服务框架相比，框架的优点有：1、高性能（实测在当前的框架排名第一，欢迎大家参与测试）；2、多语言（除了JAVA框架外，第一个提供商业版的GO语言开发框架，紧跟当前容器生态的潮流）；3、Mesher（提供对业务0修改的ServiceMesher能力）4、提供了可视化的服务管理（治理）能力，如果灰度发布、路由管理、限流降级、熔断容错、可视化仪表盘等，让应用更好地满足当前大流量时代服务高SLA指标的要求。至于缺点，大家可以共同的去挖掘一下，框架出来较晚，肯定还存在较多不成熟和待改进的地方，代码都已经开源，大家可以直接到社区查看，或者使用商业服务： apache/incubator-servicecomb-java-chassisgithub.com apache/incubator-servicecomb-service-centergithub.com apache/incubator-servicecomb-sagagithub.com

1. 设置了对服务自动熔断，在熔断时间窗内，调用其他接口没有报熔断错误 场景描述：设置了所有接口为自动熔断，构造一个接口处理异常，调用该接口出现熔断，但是调用其他接口没出现熔断。 问题分析：CSE的熔断的粒度是方法级别的，针对的是微服务的所有方法。即当一个接口出现错误发生熔断后，该微服务（而不是这个实例）的接口调用都会熔断，而不会影响到其他服务，或者本服务的其他接口。 2. 设置对服务的自动熔断，过了熔断时间窗口，调用熔断的测试接口依然报熔断错误 场景描述：设置对服务的接口进行熔断，构造异常，出现熔断。然后等待时间窗过去后，重新调用，仍然熔断。 问题分析：如果服务已经处于熔断状态，到了下个时间窗，会进行重试。如果失败，那么立即会进入熔断。

本帖最后由 李白云 于 2018-2-3 11:34 编辑华为云CSE微服务引擎是业界首个商用的企业级微服务应用管理平台，包含微服务Java SDK、Go SDK、Mesher，为用户提供统一的服务注册、配置和治理控制台，可轻松实现微服务应用的快速开发和高效运维。 日前，华为云CSE(Cloud Service Engine)正式推出的产品级Go语言微服务框架Go Chassis。借助CSE Go Chassis进行微服务开发可最大化地降低开发门槛，提升产品上线速度,同时可以获得微服务运行时高可靠性保证、运行时动态治理等一系列开箱即用的能力。 在不久前CSE刚刚发布了基于Service mesh技术的CSE Mesher，支持Net、Node.js等语言应用能够以零侵入模式接入CSE微服务治理，本次Go语言微服务框架的发布，不仅意味着CSE正式拥抱Go生态系统，同样意味着CSE已提供Java、Go、NET、Node.js、PHP等多语言微服务解决方案，这给了企业及开发者提供了更大的选型空间，使企业可以高效复用现有的语言能力和软件资产。 Go语言：云计算新一代开发语言最近，Go语言之父，Google大神Rob Pike在博客里谈到了Go语言十年的成长，其中尤其是在云计算领域的发展速度让他感到震惊。Docker使用Go语言催化出云计算领域的容器行业。并且从Google趋势图中可以发现，Go在中国的使用非常火爆，并且截止目前Go社区在全球已有50万gopher。 Go语言语法特性简单、更加人性化的并行和异步编程；用更少的代码做更多的事、关注程序执行效率和性能。同时Go语言有Google这样的一流技术公司在后面，Go语言杀手级的应用docker，其生态圈在近年已经爆棚，已经获得了实践的广泛认可。10191 CSE Go Chassis 简化开发灵活可靠作为业界首款商用级别的Go语言微服务框架，Go Chassis已具备支持企业级应用的核心特性： ▷ 可定制的通信协议：除了现有支持的HTTP/ Highway RPC协议外，用户可自行扩展协议。支持Go Chassis开发的应用与使用Java Chassis开发的应用互相通信，企业在进行微服务架构选择有更大的自由。▷ 使微服务更加健壮：完善的服务治理（负载均衡、限流、熔断、降级等等），保障Go微服务应用可靠运行。▷ 运维：metrics可对接prometheus，让Go微服务应用运维无忧；并且log可下沉到不同系统，用户可按需配置log。▷ 安全：插件化的Cipher支持企业在证书、aksk等敏感数据加载时使用自己的加解密算法。▷ 灵活的处理链：支持用户自定义框架处理逻辑。 使用CSE Go Chassis开发微服务，可以最大化地简化开发门槛，提升产品上线速度。同时可以获得微服务运行时高可靠性保证、运行时动态治理等一系列开箱即用的能力。 多语言微服务解决方案CSE目前已全面支持企业应用基于Chassis和Sidecar模式进行微服务开发，无论是Java语言、Go语言或者其它语言的企业应用，均可基于CSE提供的全方位微服务解决方案使用统一标准进行微服务开发、通信、监控、治理。10192Chassis模式 用户可使用Go、Java语言微服务框架来作为微服务开发的底座，框架为其封装掉复杂性，让用户基于框架聚焦在上层业务逻辑进行二次开发。CSE Chassis提供了开箱即用的微服务治理之外，也赋予企业应用丰富的扩展能力。针对新开发的Go应用我们推荐使用此次发布的Go Chassis进行开发，通过使用Go Chassis快速开发易运维的微服务应用。 其它语言应用可使用CSE Mesher（Service mesh）以零侵入的方式CSE微服务治理中心。Mesher以Agent方式部署在应用节点上，对于不适合快速改造的老旧单体应用，Mesher提供了一种接入分布式环境的方式。 Chassis与Sidecar模式都不是银弹，它们各有优点和缺点，但Chassis与Sidecar可无缝结合，企业开发者可以因地制宜进行混编，选择真正适合企业的微服务化方案。例如很多传统企业应用是无法做到一蹴而就的架构微服务化，而在演进的过程当中，就可以考虑将单体应用一部分一部分地进行拆分。在这个过程中，已经拆分出来的基于Java/Go Chassis开发的微服务与未拆分并使用Mesher的应用之间就可实现互通和统一治理。对于企业应用开发来说，没有最好的只有最适合的，华为云CSE微服务引擎为企业提供SpringCloud、ServiceComb和ServiceMesh商业版多个开发框架的支持，支持Java/Go/.NET/Node.js/PHP/Python等多语言微服务开发和治理，致力于为企业应用微服务化提供一站式解决方案。 试用传送门：http://www.huaweicloud.com/product/cse.html

微服务云应用平台建议增加快速创建容器和虚机应用

8352 参与方式： 1 扫上图二维**名 ，并于周四晚 20:00 扫码观看 2 PC端通过网页报名和观看： http://www.itdks.com/liveevent/detail/9543 所有教程预告+材料汇总请移步：干货别错过！每周专家大咖直播+教程汇总 每周更新！{:4_87:}

本帖最后由 李白云 于 2017-12-22 09:44 编辑转自华为云公众号，原文链接：https://yun.ywork.me/yw/hw/servi ... 0a035589b04ce5a1aca ——7:03 深圳地铁五号线，程旭源一如既往地公司宿舍两点一线。2011年，计算机专业毕业的他来到目前的科技公司上班，从打杂开发一直做到开发团队leader，也从青铜级别单身狗升级为荣耀王者单身狗。 此刻在地铁里，程旭源脑子在不断运转着最近的糟心事。几年前他刚进公司那会儿，项目的代码库才八千行不到，现在已经有八十多万行，这些代码都是他带领的这个约莫三十个人的团队没日没夜地在维护。最初几年系统基本能稳定运行。最近公司请了几位流量小鲜肉代言，业务量蹭蹭蹭地增长；对系统的需求一天天地在增加，项目版本交付各种延迟，临近交付期时恨不得向天再借五百年。 这几年， 随着公司业务欣欣向荣的发展，系统压力随之增大，旭源感觉自己的身体一天天被掏空，体检单总有那么几项指标让人咋舌。有时他想放弃，在情人节加班的夜晚，他时常觉得对不起手下的兄弟们，想着不如把这老旧的八十万行代码快递给老板然后走人，回老家找一份轻松的工作，找回当年的同桌小芳。可每每想到这里，还是责任感驱使他思索，究竟哪一种方式能够真正释放开发团队的生产力，带领他的兄弟们超神？ ——8:50 到了工位，抬头一眼望去，清一色寸头，没有什么芳香，旭源已经习以为常。但隐隐今天有些不一样，转眼间忙到快下班，boss站在办公室门口向他微微招手。来到老板办公室门口，门半开着，一席乌黑的长发映入眼帘，淡淡的香水味在空中飘荡。 “小源，这位叫魏芙雾，是我们新挖来的架构师，有非常丰富的架构改造经验。” “小魏，这就是我之前给你讲的旭源，以后你们就是战友了。要一起想办法把业务交付速度搞上去啊！”老板说完后对着旭源使了个眼色{:2_31:}。 ——初次邂逅 旭源转过头，正要伸出手，当他的眼神和小魏的眼神对上的一瞬间，他愣了五秒，从来没有一个女人让他的系统延迟达到秒级以上：黑色的双眼透着一股王祖贤般的柔情，素净的脸盘带着微笑，加上白色的长裙，清新脱俗。 “旭源，你好，之前系统的架构我已经提前看过文档和资料了，领导们的意见是我们在今年年底前完成系统改造，并且至少把50%的应用先搬上云。我们大概还有四个月时间，要抓紧了。但是要注意的是我们的老系统依然要能够对外提供服务。这可能需要对业务进行微服务化“ 旭源边听心里边默念，单刀直入，一来就谈工作，这个风格我喜欢。 “那我们要怎么改造呢？有没有方案。微服务？听说过，但是没真正玩过。这块听起来不错，但是具体怎么做呢？“ “嗯，改造的方案我正在整理初稿，过几天我们一起开会谈论下，总体思路就是做把我们应用进行微服务化，按照业务拆成微服务，由全功能的小团队来负责指定的微服务。这块不止涉及技术的问题，还会涉及到组织上的调整。” “初步想法我们先选择个维度把业务拆出来，将新的应用产生的数据和旧的应用做一个同步，确保旧系统还能提供服务。” “我先给你找个工位，你熟悉下工作环境，明早我们再详谈。” 旭源安顿好芙雾后，回到工位，打开谷歌，敲入了“微服务”。看了十分钟后，他忍不住打开知乎，快速敲入“如何追到女架构师”，没有任何收获，看来只能靠自己了。回望了人生多达两次的恋爱经验，旭源想了无数搭讪的招数，最后还是用上了那招最土的办法。 ——最土的办法 “小魏啊，你这《微服务架构与实践》和《微服务设计》看简介都还不错，能否借我看几天？” “当然可以啊，抓紧时间充充电挺好的，也有利于我们的工作沟通。” 旭源拿着书回到座位，长时间高强度的项目管理让他已经很久没有静下心来好好读几本技术书籍，他决定好好翻一下，就这样一头扎进去，仿佛让他找回刚进大学的感觉。 不知不觉边看边查已接近凌晨，看着周围空荡的工位，又想着白天芙雾的话，旭源心里渐渐有点方向，老架构解耦的思路赫然浮现在了脑海里，他拿起笔迅速开始凌乱的画起了草图， 不停的拆分再拆分，旭源满意地看了看草图，虽然有些细节还没落实，但有这两本书打底，不过再熬几个晚上的事儿，想到这里旭源喘了口气，欣然回家睡觉了。 ——第二天一早 芙雾如约来到旭源的工位找他开会，但旭源加班太晚还未赶来，无聊的她瞄到了《微服务架构与实践》旁边那张草图，顺手拿起来，发现草图凌乱不失逻辑，图形蠢萌不失棱角，这不就是一个完整的微服务架构设计图吗？系统被设计拆成了九个清晰的子模块，遗留应用保护、新业务应用、数据库报表、前端应用、后端应用、借书学习、还书请饭、加班请教、回家求搭车，看到后面小魏从不禁的惊叹变成了淡淡的微笑，向窗外望了望，楼下好像是旭源的身影。 ——故事的最后 无论是北上广深里的怀梦奋发，还是老城小街下的情怀依旧，在每一位有思想的躯体下，不忘初心，方得始终，依旧是我们所坚持的信念。或许，你没有魏芙雾相伴，或许，你还没邂逅程旭源。但华为云，以及华为云微服务引擎，一直坚守初心，为企业提供专业微服务解决方案，为联接现在与未来，奋斗。 ——最后的最后你的“微服务”找到了吗？欢迎你留言和我们分享你在云化转型过程当中痛苦和故事！

本帖最后由 李白云 于 2018-2-5 09:14 编辑（需登录华为云账号登录） 议题1：云时代PaaS技术演进 6879 议题2：华为云缓存服务技术变革历程 6880 议题3：云数据库中间件的前世今生 6881 议题4：微服务演进之道 6899 议题5：Demo演示 基于微服务框架开发的天气预报系统：http://support.huaweicloud.com/cse_dld/index.html请使用《快速入门》进行体验 希望能对您有所帮助~~喵喵

本帖最后由 云飞杨 于 2017-12-12 14:52 编辑年末是大促的时节，双11的余热还未散尽，上个月的欠款刚刚还完，双12就到了。但双12是2017年的最后一个剁手节，华为云决定趁这个时候给大家放价寻开心。 活动年年做，套路也一年比一年多，今年大促的玩法堪称史上最复杂。体验过的同学都知道，优惠规则太长太难看不懂，满减处处都是坑，什么预售、定金膨胀、红包、优惠券、保价政策，分分钟把人绕晕。大胆猜想下剁手族们的内心弹幕，想必是这样的：6511 华为云深知程序猿GG的直率，反套路而行，开出史上最简单优惠模式：华为云PaaS基础服务全免费！免费！免费！（重要的事情说三遍）。{: 9_271:}PaaS领域6大主力产品全都参加本次活动。 微服务引擎CSE：企业级的微服务应用管理平台，包含微服务SDK，服务注册、配置和治理中心，从开发的运维全程陪伴，并且已经开源微服务开发框架ServiceComb。本次免费的专业版套餐最大支持500微服务实例，现在开始用，免费玩半年，不花一毫一厘就能轻松上云。 云容器引擎CCE：华为云独有的裸金属容器，提供高可靠高性能的企业级容器应用管理服务，支持Kubernetes社区原生应用和工具，此次也参加华为云PaaS免费活动，免收服务管理费。原来每小时都要花钱的CCE，这次活动目标是人人用得起，司司用得上，不管多少节点，统统免收集群管理费。 函数服务FunctionStage：一项基于事件驱动的函数托管计算服务，只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施。产品经理说，不花钱用好货，不是你的错，到2018年6月底，就是免费随便用。 若同时搭配微服务云应用平台ServiceStage、分布式消息服务DMS、分布式数据库中间件DDM使用，更可以享受先进的一站式PaaS平台服务、体验完全托管的高性能消息队列服务，让上云轻松又愉悦！ 优惠类型活动时间优惠产品免费2017.12.12—2018.6.30云容器引擎CCE 函数服务FunctionStage 微服务引擎CSE 微服务云应用平台ServiceStage 分布式数据库中间件DDM 分布式消息服务DMS（开通更送50元全场通用代金券）立即享受免费上云畅快体验。还愣着干嘛，赶紧来占我便宜啊~~{:4_87:} 6504

本帖最后由 李白云 于 2017-12-18 18:54 编辑精彩内容提前爆料，此次深圳站私享会邀请到了微服务重量级嘉宾前来分享{:3_59:} 报名方式，请访问：http://cloud.51cto.com/act/hwcloudsalon_gw/201711/page/shenzhen