1、提供GO语言微服务开发框架SDK  支持插件化注册中心、多RPC协议（已默认实现http和highway，可扩展）  提供熔断降级、容错、路由管理、限流、错误注入、灰度发布等治理能力 2、提供Service Mesh商业版  支持.NET、Node.js、PHP等多语言应用微服务解决方案，能够以零侵入模式接入CSE微服务治理，提供完善的服务治理能力  兼容Dubbo协议，支持存量Dubbo应用零侵入接入CSE 3、提供网关服务EdgeService解决方案  支持Restful请求汇聚及转发，支持服务映射、请求解析、加密解密、鉴权等自定义能力  网关服务本身也可接入CSE进行微服务治理 4、提供微服务灰度发布能力  支持按照流量权重方式  支持按接口参数自定义灰度发布规则 5、微服务流水线能力增强  支持Java，GO、多语言Docker应用一键式构建和部署  流水线已支持对接Github和GitLab，Bitbucket、Gitee、DevCloud即将上线  支持一键式创建基于GoSDK或JavaSDK的微服务工程（自动生成框架代码、编译、构建、部署脚本和环境） 6、支持对接zipkin、Apollo、Prometheus  CSE集成了Zipkin提供自动调用链追踪能力，用户无需改动代码即可启用基于Zipkin和Java chassis 的分布式调用链追踪的功能  CSE支持对接不同的配置中心（CSE ConfigCenter、阿波罗） 立即体验：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home 了解详情：https://www.huaweicloud.com/product/cse.html

本帖最后由 关羽夫人 于 2018-4-21 11:04 编辑司马懿问诸葛亮，依依东望你望的究竟是什么？原来望的就是——华为云 容器训练营。云容器引擎CCE自诞生以来就在使用说明、用户体验上狠下功夫，帮助中心、视频教程、云图说从未间断。然而所谓百闻不如一见，看教程哪有实践操作来得印象深刻。 4月23日，容器训练营正式上线，自己动手的机会来了！训练营提供初级、进阶案例，从创建集群到创建应用一应俱全，让想要体验容器的你快速玩转CCE。 看到这里，有些看过CCE教程的老朋友脑海中可能会闪过一条“温馨”提示： 14268 对，即便CCE是免费的，在使用过程中也会消耗基础设施费用。这条提示可以说是很贴心了，连充值按钮在哪儿都写得清清楚楚，看起来像诱惑程序猿的下班铃。 但是，今天的容器训练营不一样。 14267 容器训练营 完 全 免 费，我们的口号是“体验CCE，0元创集群”！ 无论新老用户，只要是首次使用云容器引擎-训练营，都能领取150代金券，人人可享。 代金券使用无门槛，无需充值即可在训练营中0门槛体验CCE的高效快捷，亲身感受华为云容器技术的内在功力。 14269下面开始体验教程： 首先，您需要登录华为云控制台，并单击体验按钮，果断领取150元代金券，否则系统将判断您为土豪哦。 请戳链接https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/guidance/list ，开始愉快创集群吧

本帖最后由 橘色祥云楼楼主 于 2018-4-20 14:52 编辑本文作者：乔雷 原华为PaaS架构师/系统和软件工程师，现Cloud BU中国业务技术支持部解决方案架构师 基于华为云的一个典型的持续部署方案：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker) [*]1. 关于持续集成（CI）和持续部署（CD） [*]2. 一个华为云上的持续部署方案 [*]3. 部署截图 摘要：华为云迄今为止已经有14大类超过100种服务了，可以做很多有用和好玩的方案。本文以一个实际的案例，讲述如何使用华为云上的相关服务(主要是FuctionStage和CCE)完成自动化持续部署（CD，Continuous Deployment)；并且通过Monucular手动部署Helm Charts打包的Kubernetes应用。这充分说明了华为云云容器引擎CCE支持和兼容开源生态Kubernetes以及在DevOps的强大能力，以及华为云支持业界主流自动化部署工具的能力。 1. 关于持续集成（CI）和持续部署（CD）在软件开发和运维领域，我们经常会听到很多概念，比如DevOps，持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)等等。这些新的概念、方法论和工具的出现，主要是为了应对目前业务的挑战。主要是要求业务推出和运维即“快”又“稳”： [*]快：比竞争对手更快的创新、试验和部署业务的能力。快速推出业务、快速获取反馈、快速迭代、快速试错。 [*]稳：快速、频繁地特性发布，同时保证业务和系统的稳定性、可用性和持久性。 下面我们稍微解释一下持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)的概念，可以去参考：持续集成是什么？ [*]持续集成（CI，Continuous Integration)：持续集成指的是，频繁地（一天多次）将代码集成到主干。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。 [*]持续交付（CD，Continuous Delivery）：持续交付指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。 [*]持续部署（CD，Continuous Deployment)：持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 在本文的场景中，主要讲述的是基于华为云的持续部署（CD，Continuous Deployment)。2. 一个华为云上的持续部署方案前期在支撑某客户在华为云上的概念验证（PoC，Proof of Concept）中，有一个很重要的测试场景：自动化CI/CD。具体场景是：客户在私有云中完成持续集成（CI），CI采用自建的工具链；生成结果自动在华为云上完成持续部署（CD），部署在Docker容器中。客户采用Helm charts脚本部署容器应用，因此在客户的CCE（Cloud Container Engine）容器集群所在的VPC中，我们部署了一台服务器安装了Helm client，通过Helm client连接CCE集群的Kubernetes Master完成Docker容器应用部署。客户部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。我们采用了：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker)的方案完成持续部署。演示效果良好。具体如下图所示：14221描述如下： [*]客户在私有云中完成持续集成（CI），CI采用自建的工具链。CI的结果是： [*]应用容器镜像上传到华为云容器镜像仓库（SWR, SoftWare Repository for Container） [*]应用部署脚本（例如Helm Chart.yaml, values.yaml）等以约定的打包方式，上传到华为云对象存储服务（OBS, Object Storage Service）的指定桶（Bucket）的相应目录下 [*]因为华为云的FunctionStage(Serverless）和OBS有集成，事先在FunctionStage中配置触发器（Trigger），当指定桶（Bucket）的相应应用目录下有文件更新时（PUT/POST操作，即用户上传了应用部署脚本），自动触发一个Python程序的执行。 [*]这个Python程序会ssh到Helm client，执行一个自动化部署的脚本。此自动化部署脚本会执行资源清理、helm install等动作完成容器应用的部署。 [*]部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。 [*]最后的结果是：应用通过helm client部署在CCE容器集群中，该创建的资源（例如RDS-MySQL）成功创建并初始化，资源和应用运行正常。 [*]当然，我们也安装了一个Monocular(Monocular is a web-based UI for managing Kubernetes applications packaged as Helm Charts)，允许用户手动部署Helm Charts打包的Kubernetes应用。 3. 部署截图一些部署的截图如下。请注意：这个截图是我手动部署的截图，跟自动化部署的截图是类似的，但更能说明部署过程。 [*]通过Helm client部署容器应用到CCE集群 14158 执行kubectl get pods可以看到应用pod(容器)处于Running状态。 [*]部署过程中通过自动化部署工具创建和初始化的华为云RDS-MySQL资源 14159

本帖最后由 大脸猫爱吃鱼 于 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-4-9 11:02 编辑排行榜链接1.重磅！华为云国内首发Windows容器服务http://forum.huaweicloud.com/viewthreaduni-6883-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-092.三亿用户量的微服务化改造 华为云是如何做到的？http://forum.huaweicloud.com/viewthreaduni-6971-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-093. 3月15日晚20:00点直播预告：使用Apache SkyWalking APM 监控 Apache ServiceCombhttp://forum.huaweicloud.com/viewthreaduni-7097-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-094.华为云正式开放区块链服务！与车车科技发布实践应用方http://forum.huaweicloud.com/viewthreaduni-7558-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-095.【CPTS新手入门】全5期，快速上手全收录！http://forum.huaweicloud.com/viewthreaduni-6829-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-096.华为云的Kubernetes实践之路http://forum.huaweicloud.com/viewthreaduni-7719-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-097.【1V1专家咨询】你来提问题，产品经理来回答！http://forum.huaweicloud.com/viewthreaduni-7146-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-098.携手开源中国，华为云容器镜像服务SWR助力用户打造DevOps流程http://forum.huaweicloud.com/viewthreaduni-6990-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-099.【你问专家答】与技术大咖的亲密交流之旅---#云容器实例#http://forum.huaweicloud.com/viewthreaduni-7211-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0910.华为云应用服务大型互动专场，邀您体验趣玩黑科技！http://forum.huaweicloud.com/viewthreaduni-7265-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0911.Cloud 2.0时代，华为云推出四大云上应用服务http://forum.huaweicloud.com/viewthreaduni-7643-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0912.AOS的基本概念！http://forum.huaweicloud.com/viewthreaduni-7514-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0913.【2月干货阅读排行榜】应用服务论坛2月都爱看什么？http://forum.huaweicloud.com/viewthreaduni-6960-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0914.ServiceComb不能做api gateway，但是却有api gateway的一些功能，功能重合怎么办http://forum.huaweicloud.com/viewthreaduni-7171-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0915.【云图说】应用性能管理采集知多少http://forum.huaweicloud.com/viewthreaduni-6888-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0916.管家婆发布基于华为云Windows容器解决方案http://forum.huaweicloud.com/viewthreaduni-7562-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0917.如何在API网关上调用APIhttp://forum.huaweicloud.com/viewthreaduni-6970-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0918.配置中心的 代码会开源吗http://forum.huaweicloud.com/viewthreaduni-6869-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0919.【求助】 配置中心拉取配置时 http返回401 Unauthorizedhttp://forum.huaweicloud.com/viewthreaduni-6859-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0920.docker save后在界面上传镜像http://forum.huaweicloud.com/viewthreaduni-6918-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-09

本帖最后由 橘色祥云楼楼主 于 2018-3-29 11:36 编辑13375 华为与 Kubernetes 的渊源颇深，早在 Kubernetes 刚开源的时候就以社区创始成员及白金会员的身份加入其中。目前拥有 1 个 Steering Committee 席位和 5 个 Maintainer 席位。 华为自身基于 Kubernetes 的实践 加入初期，作为全球最大的电信设备制造商之一，华为内部 IT 运维着遍布全球的八个数据中心，在 100K + VM 中运行 800 多个应用程序，使用虚拟机封装应用程序，但每次启动虚拟机都花费了大量的时间，这给管理及部署基于虚机应用程序的高成本和低效率带来了严峻的挑战。因此华为决定利用 Kubenetes 技术对自身 IT 系统进行容器化改造。 与此同时，华为通过参与和贡献 Kubernetes 项目，为自身带来了在规划、网络、多集群联合、应用支持、安全、可扩展性和政策执行等方面的良好设计、代码和文档管理，以及在服务治理方面的收益。通过自身的容器化改造实践，在受益的同时又将自身遇到的实际问题不断的贡献给社区，与社区成员一同推动 Kubernetes 的发展。 比如，在华为内部 IT 系统的实践历程中，业务的全球化属性给平台带来了混合云、跨地域、多 DC 部署方面的需求，这与社区发展多集群联邦的理念不谋而合。因此，华为在集群联邦项目成立之初就积极参与其中，主导了架构设计以及联邦级别的无状态应用、短任务支持、集群间策略调度、应用跨集群自动伸缩等关键特性开发。目前集群联邦已在社区正式孵化为独立子项目。 另一个例子是早期的 K8S 并不支持亲和反亲和等高级调度策略，使得大型传统应用改造上云十分困难。在华为公司对应用做微服务拆分和容器化改造的过程中，最典型的问题就是拆分后的组件间如何高效地通信。在传统方案中，往往有多个组件的业务进程部署在同个虚机上，组件间交互可以通过进程间通信来实现。应用改造后，组件变成了 k8S 中的 Pod，被相对独立地调度和拉起，通过容器网络互相通信。当一个复杂应用的各个组件十分分散时，网络通信的时延会大幅增加。 一方面，针对这个问题，华为在 k8S 社区的主导实现了节点亲和反亲和调度、应用间亲和反亲和调度、Taints tolerations 等高级调度机制。通过给 Pod 配置高级调度策略干预应用组件的分布，配合容器网络在路由策略上的优化，访问时延问题得到了显著的改善。 另一方面，在集群规模和性能方面，华为也做了很多探索与实践。面对大规模场景下海量 Service 的管理性能问题，华为设计实现并向社区贡献了使用 IPVS 管理 service 路由规则的方案，将 k8S 对 service 的管理规模从上千提升到了数万的级别。 华为云应用服务与 Kubernetes 华为云应用服务产品均围绕着“容器”为中心构建，致力于帮助客户容器化的应用在云上高效地开发、交付与运维，并保障应用运行时的高性能、高可靠、高弹性。目前，华为云应用服务产品以基于 K8S 的华为云容器引擎（CCE）为核心，协同补齐了完整的应用开发、交付与运维流程，为客户提供完整的一站式云上应用生命周期管理方案。 华为云应用服务大体上可以分为三大类： 第一类围绕着 Kubernetes 核心功能，也就是容器编排与调度，与下层的基础设施层包括计算、网络、存储，以及水平的权限控制、网络防护、镜像仓库等服务进行整合形成一个容器化基础设施平台，并向上对接到集群管理、多 DC/AZ、多区域管理实现云上的水平弹性。通常大家所提到的“容器服务”或“容器云”大部分都是指这一类服务。华为云所提供的云容器引擎（CCE）、云容器实例（CCI）归属于此类。两者均基于 Kubernetes 构建，但技术路线偏重点有所区分。 CCE 的服务形态是用户专属的 Kubernetes 集群（Kubernetes as a Service），用户能够控制整个 Kubernetes 集群的资源与应用，并且可以调用完整的 Kubernetes API，以及安装各类 Addon 以及自定义扩展比如调度器、工作负载控制器等；而 CCI 的服务形态是无服务器容器（Serverless Container），用户无需感知 Kubernetes 集群，通常只需要调用 Kubernetes Workload API 进行应用的管理即可，而把资源全部交由华为云进行自动调度与管理。因此，通常 CCE 适合业务半托管的场景，即用户自身有一定运维能力，且业务场景需要用户手动做一些管控比如资源规划、弹性伸缩，甚至自定义一些平台特性以适配业务；相对而言 CCI 适合业务全托管的场景，即用户只需关注以容器形态所交付的应用本身，无需关注资源管控，甚至无需关注 Kubernetes 的相关原理。 第二类服务围绕着 Kubernetes 标准化接口以及结合具体场景的最佳实践来构建完整的应用开发、交付与运维流程，实现云上的应用全生命周期管理。华为云在开发阶段提供微服务开发框架帮助用户在产品开发中落地微服务架构实践，在交付阶段提供“从代码到容器镜像”的自动镜像构建服务，支持一键式部署到 Kubernetes 平台之上，实现持续交付，而最终业务上线运行之后的运维阶段除了基础的容器监控、日志、告警系统之外，同时提供了微服务治理引擎，以及应用性能管理用于故障在线辅助与自动定位。 具体举例而言：[indent] [*]华为云微服务引擎（CSE）提供了具备升降级、容错、熔断等完整服务治理能力的微服务框架，兼容 Spring Cloud、Dubbo 等开源接口，并与 CCE 深度整合，支持 ServiceMesh，未来计划进一步与 CNCF 基金会各微服务相关项目，尤其是 Istio 生态相结合，提供最适合在 K8S 之上运行业务所使用的微服务开发框架 [*]华为云应用编排服务（AOS）提供了以应用为中心的高层编排引擎，能够将 K8S 上运行的各种工作负载、各类资源对象整合管理，并提供了完善的版本与生命周期管理机制，便于客户以更高层的“应用”为对象进行日常交付与运维管理 [*]华为云应用性能管理（APM）提供了丰富的各类运维工具，除了基础的监控、日志与告警，进一步面向故障定位与分析场景提供了应用全局性能拓扑展示与调用链跟踪等高级特性，使得运维人员能够及时了解应用健康状态并进行相关处理。 [/indent] 第三类则是直接在 Kubernetes 之上身体力行地构建一些典型服务化应用，针对某些业务场景提供更易用、更高效的服务，使得客户更聚焦自身业务逻辑。比如：[indent] [*]以分布式数据库（DDM）、分布式缓存（DCS）、分布式消息（DMS）为代表的云化中间件服务，供应用业务逻辑所调用，辅助客户应用的容器化、无状态化、微服务化开发或改造； [*]以 CCE/CCI 为基础设施层所构建的 Serverless Computing（FunctionStage）服务，面向 Event-Driven 的典型业务流场景简化应用代码逻辑，并基于容器热启动、各类主流语言运行时的快速启停优化，实现更高效、更低成本的实时计算； [*]区块链服务 BCS 则提供了主流的 Hyperledger 开源框架，并基于 Kubernetes 的高性能实现 3 分钟一键上链，2000+TPS 的并发区块处理能力，可满足联盟链与私有链的各类业务场景诉求，使客户免运维地使用区块链构建自有业务框架。 未来：紧随社区版本 持续优势创新 纵观华为在 Kubernetes 上的创新可以总结为优势创新、场景创新、技术创新三个层面，优势创新是围绕华为固有的自身强势领域如网络、硬件进行与容器技术的结合运用。场景创新则是聚焦在不同领域的客户需求如游戏、电商、AI 等，基于客户的计算需求进行解决方案的适配。技术创新，以无服务器容器为例，在 Serverless 的云服务趋势下，华为云提供更加便捷，更加全新理念的容器服务方式。目前看来，容器服务并没有统一的服务标准，并没有说哪一种创新可以一招解决所有企业云上容器化的痛点，这需要根据客户的业务场景进行量身匹配，而华为云的全栈容器服务的实践案例也充分说明了这一点。众多不同的容器服务在上线不久已应用在众多不同领域，裸金属容器已成功运用在一部分游戏客户中，帮助其进行测试环境，及高峰时间的流量应对。Windows 容器成功运用在传统 IT 系统的容器化改造，而无服务器容器则可以帮助更多缺乏 Kubernetes 技术投入的公司快速上手享受容器化带来的益处。 这也就是华为云对于 Kubernetes 的一些探索和思考，未来还会有更多基于容器的创新，一切才刚刚开始。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~作者简介 华为云应用服务技术团队，在容器与微服务领域具备长期的技术与实践积累，以领先的容器与微服务等云原生技术专注解决应用上云前后的技术难题，助力企业应用上云更加简单、运行更高效。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 活动推荐 随着 AI、Big Data、Cloud 的逐渐成熟，FAAS、CAAS 等技术的兴起，以及被运维业务的多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，AIOps 智能运维、大数据运维、ChatOps、SRE、Chaos Engineering、微服务与容器运维等新技术和方向应运而生，它们一方面把最前沿的技术结合到运维中来，一方面在人员角色、领域范围、文化等方面又有了很多扩展，让传统运维有了翻天覆地的变化。来 QCon 北京 2018 与国内外一线技术专家探讨运维前沿技术趋势，及其最佳实践和落地方略。目前大会 9 折报名中，立减 680 元。有任何问题欢迎咨询票务经理 Hanna，电话：010-84782011，微信：qcon-0410。13376 [/indent]

与产品经理对话的问答直通车，各个服务火速直达，为您做了最全整合，马上前往！ {:9_88:} 你想不想和大神来一次 “亲密”的技术交流吗？你在产品使用中是否遇到了疑惑？你有不吐不快的话想要向产品经理直接诉说吗？1.微服务云应用平台2. 云容器引擎3.微服务引擎4.函数服务5.应用性能管理服务6.应用运维管理7.应用编排服务8.API网关9.云性能测试服务10.容器镜像服务11.云容器实例直达问题版块发帖提问，产品经理真的会粗线哒哒哒！！！ 详细规则请参见各版块，就是简简单单——发帖发帖，没有门槛啦~欢迎回复本帖，表达你们的爱与问候~{:4_87:}

本帖最后由 橘色祥云楼楼主 于 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-3-8 10:06 编辑每月整理的干货排行榜，看看大家都在看什么热门文章吧！{:2_26:} No.主题链接1来了！华为云区块链服务BCS产品正式发布http://forum.huaweicloud.com/vie ... ewsletter2018-03-012什么是华为云PaaS服务http://forum.huaweicloud.com/vie ... ewsletter2018-03-013程序猿们，容器镜像了解一下。。。http://forum.huaweicloud.com/vie ... ewsletter2018-03-014请问一下ServiceComb和SpringCloud相比优势有哪些？http://forum.huaweicloud.com/vie ... ewsletter2018-03-015知乎精选：华为微服务框架ServiceComb适用于什么场景， 与业界其他微服务框架对比的优缺点http://forum.huaweicloud.com/vie ... ewsletter2018-03-016REST与Highway RPC二者相比，性能如何？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0172月8日晚20:00点直播预告：Java Chassis通信处理详解http://forum.huaweicloud.com/vie ... ewsletter2018-03-018连接注册中心时认证失败，报错： "errorMessage":"Request unauthorized"http://forum.huaweicloud.com/vie ... ewsletter2018-03-019使用ServiceComb从0搭建服务遇到的坑http://forum.huaweicloud.com/vie ... ewsletter2018-03-0110节点docker配置使用direct-lvm模式指导http://forum.huaweicloud.com/vie ... ewsletter2018-03-0111《Service Center设计揭秘》直播干货：直播回顾+材料下载http://forum.huaweicloud.com/vie ... ewsletter2018-03-0112《Java Chassis通信处理详解》直播干货http://forum.huaweicloud.com/vie ... ewsletter2018-03-0113import cycle not allowedhttp://forum.huaweicloud.com/vie ... ewsletter2018-03-0114【CPTS新手入门】第2期：如何进行环境资料准备？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0115通过APIG调用函数服务生成图片存储在OBS并返回其URLhttp://forum.huaweicloud.com/vie ... ewsletter2018-03-0116为什么选不到执行机节点？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0117【CPTS新手入门】第5期：如何查看测试报告？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0118【CPTS新手入门】第3期：如何创建测试工程？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0119【CPTS新手入门】第1期：如何快速使用CPTS应用性能服务？http://forum.huaweicloud.com/vie ... ewsletter2018-03-0120使用tomcat部署应用，注册的地址包含两个实例http://forum.huaweicloud.com/vie ... ewsletter2018-03-01

帖子内容主要总结了了Linux磁盘管理基础知识。其中包括存储设备的挂载和卸载常用操作命令、自动挂载操作命令和磁盘分区操作命令等。 一、存储设备的挂载和卸载存储设备的挂载和卸载常用操作命令：fdisk -l、df、du、mount、umount。fdisk -l 命令1.作用查看所有硬盘的分区信息,包括没有挂上的分区和USB设备，挂载时需要用这条命令来查看分区或USB设备的名称，比如挂载U盘时。注意：Linux中既然硬件是以文件形式存在，则也可以ls -l /dev/sda*查看第一块硬盘的分区信息df 命令1.作用统计磁盘空间或文件系统使用情况，显示磁盘分区上的可使用的磁盘空间，默认显示单位为KB2.格式df [option]3.[option]主要参数-a或-all：显示全部的文件系统-h或--human-readable：以可读性较高的方式来显示信息-T或--print-type：显示文件系统的类型4.应用举例查看全部文件系统：#df -adu 命令1.作用查看文件或目录的磁盘使用的空间，和df命令有一些区别。注意：①du后若不加目录名或文件名，表示只显示当前目录下面的子目录的目录大小和当前目录的总的大小②可查看多个文件或目录用空格符隔开2.格式du [option] 目录名或文件名3.[option]主要参数-a或-all：显示目录中个别文件的大小-h或--human-readable：以K，M，G为单位显示，提高信息可读性-S或--separate-dirs：省略指定目录下的子目录，只显示该目录的总和（注意：该命令是大写S）4.应用举例以易读形式查看ahao目录的大小并忽略子目录：#du -h -S ahao以易读形式查看haha1文件和haha2文件的大小：#du -h haha1 haha2mount 命令1.作用①此命令后面不加任何参数表示查看已挂载的所有文件系统②加参数表示将存储设备挂载到Linux的一个目录下，从而将分区和该目录联系起来，因此我们只要访问这个目录，就相当于访问该存储设备了。注意：当一个目录之前有文件，设备挂载到这个目录后，目录不显示之前的文件2.格式mount [option] 设备名挂载点(必须已存在)3.[option]主要参数-t文件系统类型>:文件系统类型vfat表示FAT32，iso9660表示光盘或光盘镜像，auto表示系统自动识别(一般选这个方便吧)4.应用举例将FAT32文件系统的分区/dev/sda5挂载到/ahao目录下：#mount -t auto /dev/sda5 /ahao将U盘/dev/sdb1挂载到/ahao目录下：#mount -t auto /dev/sdb1 /ahao将光盘镜像文件xxx.iso的挂接到/peter目录下：#mount -t iso9660 xxx.iso /peter -o loopumount 命令1.作用卸载已经加载的文件系统。利用设备名或挂载点都能umount文件系统，不过最好还是通过挂载点卸载，当一个设备多个挂载点时容易产生混乱2.格式①umount 挂载点 (推荐此方式)②umount 设备名3.应用举例在使用umount命令卸载文件系统时，必须保证文件系统不能处于busy状态，使文件系统处于busy状态的情况有：文件系统中有打开的文件，某个进程的工作目录在此系统中，文件系统的缓存文件正在被使用等。最常见的错误是在挂载点目录下进行卸载操作。卸载/ahao挂载点对应的挂载：#umount /ahao二、自动挂载自动挂载实现原理实现开机自动挂载只需修改/etc/fstab配置文件即可，可用vi编辑器修改或图形界面下用gedit命令修改/etc/fstab配置文件解读打开/etc/fstab配置文件⑴第一列：①设备名/dev/sda1或②卷标label或③设备UUID(红帽6)（查看设备的UUID blkid/dev/sda1）⑵第二列：挂载点⑶第三列：文件系统类型⑷第四列：挂载选项，通常使用defaults就可以⑸第五列：是否进行备份，1表示备份，0表示不备份⑹第六列：是否检查文件系统，1表示检验，0表示不检验应用举例实现插U盘自动挂载U盘到/usb目录，不备份且不检查文件系统：/dev/sdb1 /usb auto defaults 0 0将上述命令添加到/etc/fstab配置文件中即可完成插U盘自动挂载，为了避免可能的错误，使用mount -a 命令来检验编辑的内容是否有错三、磁盘分区用fdisk在Linux中进行分区的时候，最常用的参数分别是 d、l、m、n、p、q、t、w等。注意：①主分区和扩展分区的磁盘号位1-4，也就是说最多有4个主分区或者扩展分区，逻辑分区开始的磁盘号为5②如果硬盘上有扩展分区，就只能增加逻辑分区，不能增加扩展分区了fdisk 命令1.作用对硬盘进行分区，采用传统的问答式界面2.格式1)fidsk 磁盘名2)[option]第一步：fidsk /dev/sdb ：选择要进行操作的磁盘，这里是对sdb移动磁盘进行操作第二步：输入[option]进行操作3.[option]主要参数m:列出可以执行的命令（帮助）p:查看磁盘目前的分区情况n:建立新的磁盘分区l:列出已知的分区类型d:删除现有分区t:改变分区类型w;对分区操作进行保存并且退出q:不保存退出分区过程描述①通过 p 参数来查看出硬盘分区表信息。根据信息确定将来的分区②通过 d 参数一个个删除存在的硬盘分区，如果想完全改变硬盘的分区格式③通过 n 参数来增加新的分区1）选择新建的分区类型。p为主分区，e为扩展分区（当有扩展分区存在时这里的e会 变成l，即逻辑分区）2）设置分区号。主分区或扩展分区为1-4，逻辑分区为5开始3）设置分区起始位置。（一般回车默认就好）4）设置分区结束位置。（100单位为扇区，+100M单位为M，+100K单位为K）④通过p参数确认分区建立成功⑤通过参数w或q退出（w为保存并退出，q为不保存退出）注意：在增加分区的时候，其类型都是默认的 Linux Native，如果需要把其中的某些分区改变为其它类型，可以通过命令 t来改变，当键入“t”改变分区类型的时候，系统会提示要改变哪个分区，改变为什么类型（键入l查看系统所支持的分区类型及其对应的分区类型号）。四、磁盘格式化对硬盘分区之后，需要对分区进行格式化才能使用，格式化分区的主要目的是在分区中创建文件系统，文件系统是OS用作明确存储设备或分区上的文件的方法和数据结构，即在存储设备上组织文件的方法。mkfs 命令1.作用格式化分区，在分区上创建文件系统2.格式①mkfs[options] 设备名②mkfs.文件系统类型> [-v] 设备名3.[option]主要参数-t文件系统类型>: 选择要创建的文件系统的类型，如ext3、ext4等，不同版本的Linux具有不同的默认文件系统-V:显示更多输出，包括文件系统的相关信息(注意：-V必须放在-t前面)4.应用举例格式化/dev/sdb1分区，并显示具体信息：#mkfs -V -t vfat /dev/sdb1#mkfs.vfat -v /dev/sdb1 希望以上信息会对各位小伙伴们有用。

本帖最后由 DevCloud 于 2018-2-27 11:06 编辑11252 DevCloud容器部署华北区抢先上线，参与活动即可领取测试基金，助您任性体验。在本帖内反馈产品优化建议，将有机会获得关系型数据库6个月使用权（价值：￥5544）、弹性云服务器6个月使用权（价值：￥2186.4）等奖励。活动时间： 2018年2月27日-2018年4月30日参与流程： 1. 按照活动页面所示体验流程，完成华为云DevCloud部署服务的体验； 点此直达活动页面 2. 在本帖中，按照以下示例格式回复反馈意见： #意见反馈# 使用环节 + 问题描述 + 优化建议 + 界面截图（如有必要） 例：#意见反馈# 新建容器部署任务时，本地上传镜像的步骤太复杂，建议简化操作流程。活动奖励： 1. 参与奖励：活动页面内，完成账号注册、企业实名认证并接受Demo项目后，可获得100元测试基金（可用于开通华为云弹性云服务器时使用）； 2. 参与反馈意见奖励： 排行前20位可获得：主备实例关系型数据库（2核4G）6个月使用权（价值：￥5544）； 排行21-60位可获得：II代 弹性云服务器（2核4G） 6个月使用权（价值：￥2186.4）； 其他参与意见反馈的用户均可获得：华为云DevCloud 1000元奖励金券（价值：￥1000）。奖励发放方式： 1. 活动结束后，将于7个工作日内在本帖中公布排行信息及获奖名单； 2. 获奖用户请扫描下方二维码添加服务人员微信，验证信息请输入“部署”，请将华为云用户名、帖子所在楼层、姓名、联系方式发送给微信群的服务人员，奖品将于活动结束后15个工作日内发放完毕。 11253奖励评选规则： 1. DevCloud产品团队对反馈意见从价值、数量等方面进行综合评分，活动结束后依照评分以企业维度做排行并发放活动奖励； 2. 同一企业仅可获得一个奖励，同一企业租户下的不同用户可分别回复意见，但最终以企业维度统计评分； 3. 相同意见，以回复时间最早的为有效意见，其他视为无效； 4. 获奖用户请在活动结束后15个工作日内联系工作人员，否则视为主动放弃； 5. 为达到活动公平公正公开，避免恶意刷楼等行为，回复无意义内容(纯数字、标点、表情或词不达意等)、谩骂、造谣等，均视为无效。 6. 活动参与需遵守《华为云社区常规活动规则》，戳>>>这里。

以下是华为开发人员针对SWR应用中出现的具体问题做的详细解答，希望可以帮助到正在使用中的朋友！{:2_26:}1、 Q：什么是容器镜像服务   A: 容器镜像服务（SoftWare Repository for Container）是一种支持容器镜像全生命周期管理的服务， 提供简单易用、安全可靠的镜像管理功能，帮助用户快速部署容器化服务。2、 Q：什么是组织A：组织用于隔离镜像仓库，支持为不同用户分配相应的访问权限（读取、编辑、管理）。3、 Q：如何安装Docker  A：http://support.huaweicloud.com/swr_faq/swr_faq_0003.html4、Q：如何制作镜像压缩包A：http://support.huaweicloud.com/swr_faq/swr_faq_0004.html5、Q：为什么通过Docker客户端和页面上传的镜像大小不一样？A：使用Docker客户端上传的镜像每一层layer进行了tgz压缩，而页面上传的镜像包是经过docker打包的，每一层layer只进行了打包，没有压缩，所以两种方式上传的镜像大小显示会不一致。6、Q：Docker客户端上传镜像失败?A：若用户使用未创建的namespace上传镜像，返回鉴权失败，可能是该namespace已被其他用户注册，建议先创建namespace然后再上传镜像。7、Q：如何解决内网下载镜像失败？     A：http://support.huaweicloud.com/swr_faq/swr_faq_0007.html了解更多容器镜像服务请点击：http://www.huaweicloud.com/product/swr.html若有问题跟帖回复，快马加鞭为你解答{:2_37:}

容器作为一种轻量级的虚拟技术，使应用程序认为他们自己有一个专门为他们服务的完整的操作系统，其帮助开发人员实现了更简单的封装、快速的程序部署、减少程序的环境依赖并支持横向的可扩展性。然而这种通用包装服务模式，其将每个容器视为“服务单位”，大大降低了程序的透明度和可审计性， 那么我们如何在不损失容器带来的优点情况下保证容器及其内运行程序的安全性？Aqua Security做为专门为容器技术设计的安全性产品，给予企业容器虚拟环境从开发到生产整个周期的安全性，减少IT安全部门与开发部门的协调沟通成本，并对容器内部的应用程序活动具有高可见性，允许组织检测和防范可疑活动和实时攻击。其同时还通过以下几点来提高企业内部容器虚拟环境的安全性：l 定期同步Registry内的images并进行安全扫描，可根据预先设置的规则，比如CVE总体威胁级别、CVE评分等，自动禁用威胁image。l 所有的威胁扫描条目都与云端同步，保证实效性。l 可自定义image镜像执行的白名单和黑名单，也允许用户自定义Base OS image （操作系统模板镜像）。l 可与Jenkins等常用CI/CD程序整合，在自动打包image时即进行威胁扫描。l 可查看Host主机上所有运行及停止状态容器的详细信息，包括威胁漏洞、环境变量、挂载卷、已安装包、容器配置等。l 对Host及容器内部都有详细的活动日志记录。l 可针对容器运行状态设置自定义的安全规则，如只读文件、运行容器的OS用户、执行命令、挂载盘、特权参数、环境变量参数等，保证容器运行时的合规性、安全性。l 可自主学习相关容器运行时的操作，根据学习到的结果自动生成安全规则赋予容器。l 可针对Host主机的操作系统用户定义不同角色，实现用户docker相关命令的颗粒化权限管理。l 可针对容器与容器、容器与Host、Host与其他节点之间设置网络防火墙策略，实现Docker容器虚拟环境的网络监管。l 可将内部数据导入到Splunk、ArcSight等其他日志收集程序进行分析、联动l 集中化管理容器运行时的敏感信息（Secret），并以环境变量的方式注入容器。注入后密码信息只能通过容器内部获取，无法通过外部Inspect等命令得到。同时Aqua Security也支持和CyberArk、Azure Key Vault、Amazon Key Management Store等的整合，将这些敏感信息储存在这些第三方程序内并调用。 http://www.aqua-sec.com.cn 如果有需要请直接联系我们, [email]ChinaSupport@edvancesecurity.com[/email], 电话：400-099-2608。

本帖最后由 橘色祥云楼楼主 于 2017-12-22 15:23 编辑应用服务论坛精品栏目【华为云图说】系列，用视觉阅读的形式分享知识干货，持续出新！{:9_88:}有问题欢迎留言或者去爆料栏目反馈，赚取社区积分！ 云图说系列（产品服务总体介绍）新手课堂系列 （陆续推出的细节课程）图解ServiceStage第1期：初识ServiceStage微服务云应用平台【CCE新手课堂】第1期：一分钟扫盲云容器黑话 六大基本概念通俗解读图解ServiceStage第2期：应用调度与资源管理框架【CCE新手课堂】第2期：创建容器应用基本流程图解ServiceStage第3期：微服务应用开发与治理框架【CCE新手课堂】第3期：快速创建一个kubernetes集群图解ServiceStage第4期：3分钟了解ServiceStage 应用智能化运维【CCE新手课堂】第4期：3分钟创建一个游戏类容器应用图解CCE云容器引擎第1期：初识CCE云容器引擎【CCE新手课堂】第5期：为容器应用配置弹性伸缩策略图解CCE云容器引擎第2期：5大场景下适用于使用CCE容器服务【CCE新手课堂】第6期：通过Helm模板快速部署中间件应用图解CCE云容器引擎第3期：定义企业级容器云，解决客户核心问题【CCE新手课堂】第7期：一张图让你看懂CCE-初识CCE云容器引擎图解CCE云容器引擎第4期： 面向企业级功能性增强（更新中……）（更新中……）（更新中……）（更新中……）（更新中……）（更新中……）（更新中……）{:4_87:}