本帖最后由 西西 于 2018-6-19 01:12 编辑看过《超能陆战队》的朋友想必对电影中两种机器人有着浓厚的兴趣，一个是“大白”，白白胖胖的身躯加上磁性的机器人声音，让无数少女巴不得立马冲上去给一个大大的拥抱。然而电影中真正的黑科技其实是那一个个“微型磁力机器人”，有了它们，人们就可以轻松的上天、入地，创造一切可能。一个个带有磁性的小部件，一个个独立的个体。通过磁力即可互相连接，接入后即可互相通讯从而实现组合成为任何物体。总结一下此微型机器人的特性如下：1、彼此独立，通过磁力与其他机器人进行相互吸引。2、离开了群体，虽然能够继续运转，但是功能变得很单一。3、它是一种松散耦合的结构，只有这样才能够具有更强的可扩展性。 我们通过这一硬件的特性，推断一下软件领域是否进行相同的尝试？一个应用，它有多个模块，每一个模块可能是一个功能，组合起来就形成了一个应用，其架构是松散耦合的。通过这样的特征进行索引，结果被我惊讶的发现了一个真相！微服务！与“微型机器人”的特性几乎一致：1、各模块彼此独立，通过比如Rest API接口进行交互。2、每一个模块都承载着某一项功能，功能单一。3、松散耦合的结构，具有极强的可拓展性。 电影中，男主在介绍他的微型机器人时有提到在运输、建造上会有巨大的贡献。那么，微服务这样的架构在什么样的场景下可以发挥出巨大的效力呢？最简单的就是游戏。网络游戏通常是单区单服，一台机器运行若干个游戏世界。每一台机器可承载的玩家是有限的，不同的游戏世界数据是不会互通的，所以都是一个进程对应一个游戏。微服务在此场景下就可以得到一个非常好的应用。游戏有其本身的逻辑规则，业内称为游戏机制。一个游戏可能会有任务移动的机制、有道具掉落使用的机制、或者是电脑机器人的机制等。那么，为什么不把这些一个一个的游戏机制通过微服务来实现呢？比如人物移动的机制，就完全可以由微服务构成一套自治系统进行控制。它可以完全独立，自己与外部信息进行交互。未来，这一套机制完全可以进行复用，只需蒙上不同的“皮”就可以轻松运行！电影中，主角通过头戴式的意念仪器对微型机器人进行控制。对于微服务来说，一个“大脑”自然也是必不可少的。微服务的“大脑”——华为云微服务引擎。华为云微服务引擎(Cloud Service Engine) 提供高性能微服务框架和一站式服务注册、服务治理、动态配置和分布式事务管理控制台，帮助用户实现微服务应用的快速开发和高可用运维；提供Spring Cloud、Service Mesh和ServiceComb商业版作为微服务的“大脑”，相比较其他厂，华为自然是具有天然的优势，几十年技术积累可谓是厚积薄发。即使面对常用的微服务解决方案，比如Spring Cloud自建开源微服务架构，华为云也有非常强的优势：1、管理界面：提供一站式微服务管理控制台，包含服务目录、服务治理、服务配置、事务看板及新服务创建等简单易用的Web操作界面。2、多语言开发：支持JAVA、Go、PHP、.NET、Python、NodeJS及其他多种主流开发语言3、通信协议：不仅支持Rest，还支持RPC。4、Service Mesh：提供商业版Mesher，支持一键式部署。 更多优势信息可点此了解！华为云微服务引擎：https://activity.huaweicloud.com/cse/index.html?fromblog?fromblog 作者：韩非

尊敬的华为云客户：您的华为微服务云应用平台ServiceStage按需套餐包（1到50个节点，1到100个实例）到期后，您仍可免费使用至2018/12/31 23:59:59。具体收费价格近期会发布，届时请参考该服务的计费详情页，敬请关注。微服务云应用平台是面向企业的一站式应用管理服务，提供应用云上托管解决方案，帮助企业简化部署、监控、运维和治理等应用生命周期管理问题。更多关于华为微服务云应用平台ServiceStage的介绍，请您点击了解。如您在使用过程中有宝贵意见，欢迎您拨打华为云服务热线:4000-955-988与我们联系。感谢您对华为云的支持！来自：https://www.huaweicloud.com/notice/2018/20180608154235407.html

前言：微服务是微服务架构中的概念，微服务架构是指由一系列微服务组成的体系架构。每一个微服务都是一个可以独立部署的程序，微服务之间使用轻量的通信机制进行通信。这种架构是相对于单体架构来说的，单体架构是指部署的应用是一个整体，都在一个进程内。但要真正实践好微服务并非易事，本系列即是从多年实践经验中沉淀出的一些普适性但又极具操作性的规则，希望能给初入微服务领域的开发者和技术决策者一些参考。1、微服务架构原则链接：https://bbs.huaweicloud.com/blogs/6ffb13eb692611e89fc57ca23e93a89f2、微服务设计模式链接：https://bbs.huaweicloud.com/blogs/f9f5c722692611e89fc57ca23e93a89f3、微服务设计原则链接：https://bbs.huaweicloud.com/blogs/7534b27f692711e89fc57ca23e93a89f4、微服务SLA规范链接：https://bbs.huaweicloud.com/blogs/ab45734e692711e89fc57ca23e93a89f5、微服务命名规范链接：https://bbs.huaweicloud.com/blogs/df9c5b68693111e89fc57ca23e93a89f6、微服务目录规范链接：https://bbs.huaweicloud.com/blogs/7a0e02d3693211e89fc57ca23e93a89f7、微服务接口设计规范链接：https://bbs.huaweicloud.com/blogs/caa3116d693211e89fc57ca23e93a89f8、 微服务版本号规范和分支策略链接：https://bbs.huaweicloud.com/blogs/42b7d21c693311e89fc57ca23e93a89f9、微服务军规链接：https://bbs.huaweicloud.com/blogs/949d90c2693311e89fc57ca23e93a89f

本帖最后由 木头羊 于 2018-5-30 12:54 编辑如果使用最基本的服务发布的能力，ServiceComb的最小依赖是哪些？ 我们项目比较老，希望保持现有的Spring 3.x依赖不动，新增接口通过REST方式注册到service center， 我看到ServiceComb依赖的Spring版本都是4.x+，不知能否基于Spring 3.x版本进行微服务改造？

CSE微服务框架提供类似spring security的包吗，谢谢大哥们！

学习索引结构的一些案例——Jeff Dean在SystemML会议上发布的论文（下）http://forum.huaweicloud.com//thread-7868-1-1.html华为云区块链开服 | 助你五分钟成为“链”上《头号玩家》http://forum.huaweicloud.com//thread-7863-1-1.html小白都沸腾了！面对区块链技术，华为有大事要宣布啦！http://forum.huaweicloud.com//thread-8213-1-1.html重磅惊喜！45万体验金人人有份，就在云容器引擎CCE训练营！http://forum.huaweicloud.com//thread-8373-1-1.html【有奖讨论】什么微服务平台，真正加快企业交付速度 ？http://forum.huaweicloud.com//thread-8486-1-1.html打造一个企业级应用的微服务开发框架（下）---ServiceComb通信处理详解http://forum.huaweicloud.com//thread-8120-1-1.html一张图了解华为云服务http://forum.huaweicloud.com//thread-8355-1-1.html皮一下很开心！华为云立体运维解决方案 狂欢60天 全球招募使用者http://forum.huaweicloud.com//thread-8472-1-1.html华为云微服务引擎五一特供，无“微”不至，致敬每一位砥砺前行，超越时代的程序员http://forum.huaweicloud.com//thread-8407-1-1.html打造一个企业级应用的微服务开发框架（上）---从服务注册中心到服务管理中心http://forum.huaweicloud.com//thread-8107-1-1.html一个小白的华为云深度学习服务使用体验http://forum.huaweicloud.com//thread-7862-1-1.html华为云携手码云微服务平台，有礼召集微服务示范项目http://forum.huaweicloud.com//thread-8420-1-1.html物竞天择：云计算新基础架构将如何发展？http://forum.huaweicloud.com//thread-8075-1-1.htmlGOPS2018华为云运维最佳CP引领AIOps新风向http://forum.huaweicloud.com//thread-8465-1-1.html小白简述区块链技术http://forum.huaweicloud.com//thread-7889-1-1.html华为云区块链服务火热公测中，赶快参与吧！http://forum.huaweicloud.com//thread-7866-1-1.html学习索引结构的一些案例——Jeff Dean在SystemML会议上发布的论文（上）http://forum.huaweicloud.com//thread-7867-1-1.html商用级Service Mesh服务的设计之道http://forum.huaweicloud.com//thread-8078-1-1.html【解救程序员系列】ActiveMQ可以轻松上云啦http://forum.huaweicloud.com//thread-8340-1-1.html华为云：端云联合 助力创新http://forum.huaweicloud.com//thread-8071-1-1.html

2018年4月，华为云DevCloud分布式追踪技术专家吴晟受邀参加2018 QCon全球软件开发大会，就《从无名小卒到拥抱全球——Apache SkyWalking (incubating) 的发展之路》做主题演讲，分享SkyWalking的发展、4次代码重构与技术升级以及社区发展之路。 吴晟进行专题演讲技术瞬息万变，云计算和云服务器目前已经逐步的成为计算机网络中基本资源，微服务的概念也随之再一次进入开发者的视野中。通俗来说，微服务的本质就是将复杂的服务拆分成单独的个体，个体之间通过统一的协议相互沟通的一个过程，这也决定了微服务的部署应该是分布式的。许多国外大型企业已经在内部生产系统中实践了分布式理念，例如google公司为了解决监控问题，研发了Dapper分布式跟踪系统，国内类似的便是开源系统SkyWalking。SkyWalking 2017 年全票通过加入了 Apache 孵化器，作为中国首个个人发起，进入Apache的孵化项目，也是唯一一个OSS项目， SkyWalking发展到这一阶段并不容易。中国开源项目的起步较晚，而且苦难重重，在OSS这个领域，国内更是很少涉猎。SkyWalking 是由开源社区推动的项目，依赖大量的基础社区反馈，国外社区的模型和理论共享，用户压力测试回馈。从2015年起，SkyWalking经历了4次代码重构与技术升级，从开始敲入第一行代码到参与W3C trace context 标准制定，从寻找第一个对SkyWalking感兴趣的人到获得Google、Micosoft、Zipkin、AppDynamic、New Relic、DynaTrace、Instana等一系列世界等级公司的尊重与重视，SkyWalking证明自己的实力、造就如今的设计和性能用了3年的时间。SkyWalking是针对分布式系统的 APM 系统，也被称为分布式追踪系统。V5版本的SkyWalking支持： [*]高性能纯流式分析 [*]高性能自动探针 [*]良好的手动探针接口 [*]分析、告警能力 [*]接入安全控制 [*]现代化UI [*]多语言社区整合 SkyWalking V5架构图除此之外，在SkyWalking的生态方面，吴晟介绍到：“目前有很多公司和个人在参加SkyWalking这一项目，4 位 PMC 成员，6 位 Committer Team 成员，总贡献者超过30位，很多贡献者目前或曾经都是APM 公司的架构或者核心研发工程师，所以SkyWalking能够提供很多商业产品或者国外产品的能力。”据了解，目前已有多家企业包括华为、当当、小米、海尔消费金融、易企秀、商云、随行付等都开始应用SkyWalking支撑企业内部研发。例如，目前SkyWalking已经作为运维监控与诊断工具对华为云DevCloud产品服务提供全流程追踪。华为云DevCloud是作为华为云的组成部分, 是华为30余年研发实践和前沿理念的结晶，为开发者提供一站式、轻量级的DevOps工具服务，支撑企业DevOps落地，实现项目的高效、高质量迭代。有了SkyWalking的应用，华为云DevCloud将进一步增强故障诊断能力与性能监控能力，也能更好的为广大开发者提供稳定可靠的云上服务。

近两年，微服务俨然是一个“火”的热点。对于大型系统来讲，微服务架构以其更加灵活、细粒度的方式使得应用之间耦合更低，团队之间协作更加清晰，交付速度更快，受到了越来越多企业的青睐。 但伴随越来越多的企业开始采用微服务，另一个问题也开始摆在了我们的面前：当大的单体应用被拆成了微服务，微服务越来越多时，如何管理这些复杂的依赖关系成了一个巨大的难题，这个时候，选择什么样的微服务平台尤其重要。那么到底什么样的微服务平台，是真正能保障开箱即用的治理能力同时，又能够帮助用户更好地管理微服务，保障系统整体稳定性呢？ 今天我们就一起来煮酒话微服务，欢迎畅所欲言，期待你的观点哟~ 1、什么样的微服务平台，能真正加快企业交付速度？（说明理想中这个微服务平台的特点） 2、你认为哪些应用适合用在微服务上？ 如果您使用过华为微服务产品，可以继续以下讨论： 3、结合您的行业，您觉得华为微服务框架ServiceComb可适用于什么场景？ 4、基于第三代微服务技术ServiceMesh的CSE Mesher已上线，您看好这个特性吗？ 华为云微服务引擎 CSE：华为云微服务引擎(Cloud Service Engine) 提供高性能微服务框架和一站式服务注册、服务治理、动态配置和分布式事务管理控制台，帮助用户实现微服务应用的快速开发和高可用运维；提供Spring Cloud、Service Mesh和ServiceComb商业版 前往体验>>：https://www.huaweicloud.com/product/cse.html 延伸阅读：1、深入揭秘华为企业级微服务架构的实践之道https://bbs.huaweicloud.com/blogs/20f18c5149e211e89fc57ca23e93a89f 2、打造一个企业级应用的微服务开发框架（上）---从服务注册中心到服务管理中心 https://forum.huaweicloud.com/thread-8107-1-1-220.html 3、打造一个企业级应用的微服务开发框架（下）---ServiceComb通信处理详解 https://forum.huaweicloud.com/thread-8120-1-1-220.html 参与方式：直接在本帖回复您的评论活动时间：2018年4月28日-5月11日 活动结束后，我们会抽取优质评论奖5名送出20元天猫超市无门槛购物卡 14678

本帖最后由 李白云 于 2018-4-28 09:25 编辑随着近年来微服务的发展，许多团队开始将自己的单体应用改造为微服务。通常Java或Go的应用可以通过业界已有的微服务框架作为微服务开发和改造的底座，封装掉解决跨网络问题带来的复杂性。但以Chassis模式进行的微服务改造有两大问题：多语言框架支持问题和侵入式改造代码问题。在这个基础上SideCar模式提供了另外一种接入分布式环境的方式，它使原有应用不与任何框架，平台或者服务绑定。对业务代码0侵入，因此不需要考虑SDK和应用如何结合，不存在较高的学习曲线和耗费较长的开发周期。这种作为基础设施层服务的存在，称为ServiceMesh。通过ServiceMesh，类似.NET或NodeJS等常见的Web应用不用考虑语言问题，寻找适合各自语言的为服务框架，也不需要侵入式修改代码就能快速接入微服务系统。整体部署方案从实现的角度看，CSE mesher是ServiceMesh模式的一种实现，它基于CSE GO-SDK开发，通常以SideCar的方式与业务服务部署在一起。它是一种网络代理的存在，业务服务并不感知，只需要配置其http_proxy为CSE mesher的地址即可。下图是CSE微服务案例中在线袜子商店SockShop的一个示例。整个SockShop由七个微服务组成，其中user等服务作为服务提供者通过java-chassis或go-chassis注册到服务注册中心。另外front-end是NodeJS实现的前端服务应用，orders是实现订单服务的.NET应用，他们通过mesher接入服务注册中心和配置中心，具备了服务发现以及服务治理的基本能力。14407 在线袜子商店SockShop架构.NET应用与mesher订单orders服务是SockShop在线袜子商店的一个子服务，主要提供订单处理（查询订单、运费计算、创建订单），订单状态查询功能。对接mesher与orders服务，只需要配置完整的代理地址，不需要对orders服务代码做任何修改。此时orders作为服务消费者访问payment和shipping服务，将由mesher完成相关微服务的服务发现和负载均衡，并把请求转发到后端服务，整个过程orders服务本身并不感知。[code]powershell export http_proxy=http://127.0.0.1:30101[/code]需要注意的是为了使请求通过代理，由mesher管理运行时，不支持使用Halkit框架的.NET服务。访问其他服务的代码可使用简单的WebRequest，示例如下。[code]java var shipmentData = System.Text.Encoding.ASCII.GetBytes(JsonConvert.SerializeObject(AShipment).ToString()); WebRequest shipmentRequest =WebRequest.Create(AppSettings.ServiceEndpoints.ShippingServiceEndpoint);[/code]其中ShippingServiceEndpoint配置为http://shipping/shipping。该请求经过mesher时，shipping作为服务名在mesher中进行解析和负载均衡。[code]json { "ServiceEndpoints":{ "PaymentServiceEndpoint":"http://payment/paymentAuth", "ShippingServiceEndpoint":"http://shipping/shipping" }, "Data":{ "MongoConnection":{ "ConnectionString":"mongodb://127.0.0.1:27017/", "Database":"data" } }, "Logging":{...} }[/code]配置和启动mesher本例中mesher启动在本机的30101端口，.NET应用orders通过mesher与其他微服务通信。mesher本身也是通过go-chassis构建的服务，可以通过chassis.yaml配置文件配置监听地址以及对接的服务中心地址。默认的go-chassis会注册自己到本地30100端口启动的service-center。[code]yaml protocols: http: listenAddress:x.x.x.x:30101 # listen addr of mesher service: registry: address:http://x.x.x.x:30100 # uri of service center scope:full #set full to be able to discover other app´s service watch:false # set if you want to watch instance change event autoIPIndex:true # set to true if u want to resolve source IP to microservice[/code]为了使orders称为服务提供者需要给mesher配置环境变量SPECIFIC_ADDR为orders服务本身暴露的地址。[code]powershell export SPECIFIC_ADDR=127.0.0.1:80[/code]通过mesher访问后端微服务orders订单服务作为消费者调用payment与shipping这两个服务。这两个服务的注册通过microservice.yaml来配置自己注册的微服务名和版本，默认版本为0.01。另外可以通过配置chassis.yaml来指定应用ID，默认的应用ID为default。启动SDK接入的微服务后同样可以在service center中查询到。yaml 微服务的私有属性[code]service_description: [/code]微服务的公共属性[code]APPLICATION_ID: sockshop[/code]设置http_proxy为mesher的监听地址后可以通过curl命令访问接入系统的其他服务。查看mesher日志可以看到mesher负责服务发现，解析出payment服务注册的advertise地址。[code]powershell export http_proxy=http://127.0.0.1:30101 curl http://payment/health[/code]运行.NET应用orders服务在创建订单过程包括对订单详细信息处理、调用payment服务的订单支付接口进行订单支付、调用shipping服务接口进行订单运送处理，最后将订单存入mongodb当中。换言之，Orders服务既作为订单服务的提供端，也作为支付和运送服务的消费端。在carts中添加袜子后点击[Proceed to checkout]即可在orders页面查看订单。14408 在线袜子商店SockShop主页 华为云微服务引擎 CSE ，截止到2018年6月30日 限时免费立即体验：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home了解详情：https://www.huaweicloud.com/product/cse.html

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

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-26 18:37 编辑无“微”不至，致敬每一位砥砺前行，超越时代的程序员！华为云微服务引擎近期大量新特性上线，诚邀您免费体验： 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支持对接不同的配置中心（CSEConfigCenter、阿波罗） 华为云微服务引擎 CSE ，截止到2018年6月30日 限时免费立即体验：https://console.huaweicloud.com/cse/?region=cn-north-1#/cse/home 了解详情：https://www.huaweicloud.com/product/cse.html 体验过程如有任何问题欢迎在微服务引擎专区留言，我们会将您的建议直通给产品经理哦~~

本帖最后由 橘色祥云楼楼主 于 2018-4-20 15:33 编辑本文作者：乔雷 原华为PaaS架构师/系统和软件工程师，现Cloud BU中国业务技术支持部解决方案架构师 摘要：华为云迄今为止已经有14大类超过100种服务了，并且更多的新服务还在不断上线中。众多的服务不仅让客户眼花缭乱，要理解这些服务并根据客户的需求做出合理的解决方案，即使是专业的技术人员也有时候力不从心。本文试图以华为云如何使能云原生应用（Cloud-Native）这一场景，以一张图的方式梳理一下对华为云服务的理解。 1. 关于云原生应用云原生应用（Cloud-Native）这两年很热门，例如拥有火爆的Kubernetes项目的CNCF的全称就是Cloud Native Computing Foundation。不同的人对云原生应用有着不同的理解，我个人比较倾向Pivotal公司一个比较狭义的定义：Cloud-Native=DevOps+continuous delivery+ microservices+containers。详情请见：https://pivotal.io/cloud-native 2. 华为云如何使能云原生应用以下这张图，来自于我前一段时间答标某项目的RFP。这个RFP中客户招标几个核心的应用。除了对应用本身功能的要求，客户还要求是云原生应用，使用云基础设施，采用目前流行的DevOps，微服务，容器，大数据/AI等技术。因此我画了一张Huawei Cloud Enables Cloud-Native Applications的PPT，重点讲解华为云如何使能云原生应用。我引用在这里供大家参考和探讨。 14160概要解释如下： [*]服务开发者使用华为云的软件开发云(DevCloud）完成DevOps中的Dev部分。一般用户会有几个环境，例如：开发（Develop），测试（Test），预生产（Pre-Live），生产(Live）。名称和阶段可能不同，但大致如此。DevCloud支持灵活定义各个阶段和每个阶段的动作。 [*]软件以微服务的方式开发，用华为云的微服务引擎(CSE)管理。部署应用时可以通过应用编排服务(AOS）编排应用，资源模板服务(RTS）编排资源。AOS是华为自研的遵循TOSCA规范的应用编排服务，RTS是华为云兼容OpenStack Heat标准的资源编排服务。 [*]微服务运行在容器服务（CCE）或者虚拟机（ECS）或者其它计算实例中。这些计算实例会挂载存储资源，例如块存储（EVS），文件系统服务（SFS）；同时，这些微服务可能会用到一些中间件服务，例如关系型数据库（RDS），分布式缓存（DCS），分布式消息服务（DMS），文档数据库（DDS）等。 [*]微服务提供的能力通过API网关和弹性负载均衡（ELB）向外暴露，供第三方应用开发者调用，形成API经济。对外的IP地址可以通过安全服务，例如Anti-DDoS，WAF等保护起来。 [*]微服务本身会调用部署在用户私有云的其它后端服务，这部分服务的生命周期不由华为云管理，可以通过云目录服务（CCS）接入。 [*]身份认证（IAM）、基础设施监控（CES）、日志服务（LTS）、云审计服务（CTS）、应用性能监控（APM）、应用运维服务（AOM）等构成了通用的管理服务。其中CES和华为云20+云服务集成，提供数百个监控项。AOM和APM一起可以提供比较完整的应用运维。 [*]微服务云应用平台（ServiceStage）是一个一站式的提供云原生应用端到端生命周期管理的平台。 [*]微服务产生的日志和记录等，可以作为大数据/AI（EI）的数据源。如下： [*]历史数据/批处理/离线处理：MRS(HDFS->HBase->Spark)或者OBS->UQuery（小型场景） [*]流数据/实时/在线处理：MRS(Flume->Kafka->Storm)或者DIS->CloudStream [*]深度学习：OBS的离线数据（定时/批量训练），或者Cloud Stream的流数据（增量训练）进入深度学习服务（DLS）进行模型训练，然后进行模型发布，进行预测。预测能力通过REST APIs的方式发布，和服务进行集成。 当然以上只是典型场景的描述，也并没有涵盖所有的华为云服务。但是把华为云如何使能云原生应用基本说清楚了。 3. 一张更详细的图PPT一页太小了，很多东西画不下。因此我用visio画了一张更详细一点的，供参考。如下： 14161 附件原图更清晰：

本帖最后由 打得一拳开免得百拳来 于 2018-4-16 17:02 编辑基于SpringBoot开发的微服务引入对ServiceComb的依赖后，本地IDE可以运行应用，但是一部署到云上就报ConfigurationSpringInitializer初始化失败。 [code]main] ationConfigEmbeddedWebApplicationContext 550 : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ´org.apache.servicecomb.config.ConfigurationSpringInitializer#0´ defined in URL [jar:file:/home/apps/service-test-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/foundation-config-0.5.0.B019.jar!/META-INF/spring/cse.bean.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.servicecomb.config.ConfigurationSpringInitializer]: Constructor threw exception; nested exception is java.lang.AbstractMethodError: io.netty.util.concurrent.MultithreadEventExecutorGroup.newChild(Ljava/util/concurrent/ThreadFactory;[Ljava/lang/Object;)Lio/netty/util/concurrent/EventExecutor;[/code] 定位思路： 1、IDE可以运行说明代码没有问题，可能是打包或者依赖包存在冲突 2、通过jar -jar启动，发现同样异常，基本确定是依赖冲突 3、参考ServiceComb社区的“使用maven管理负责依赖关系的技巧”，进行排查spring-boot、SpringCloud版本， 问题未解决 4、通过mvn clean dependency:tree 分析，对比引入ServiceComb前后依赖的变化，发现rocketmq-client引入netty-all这个包 14016 原因：netty只能引入一个版本，ServiceComb已经引入了netty相关包，这个netty-all包含了所有的版本，这才导致多版本冲突 解决方案： 在pom.xml添加排除netty-all [code] org.apache.rocketmq rocketmq-client ${rocketmq.version} io.netty netty-all [/code]总结：NoSuchMethodError、ConfigurationSpringInitializer等异常，多半是不同版本的jar包混在一起导致的冲突

本帖最后由 大脸猫爱吃鱼 于 2018-4-17 10:06 编辑 【作者】文/华为云微服务引擎团队 【摘要】近年来越来越多的企业开始实践微服务，本文分为上下两篇介绍微服务框架ServiceComb如何帮助企业应用进行微服务化，实现快速交付，并可靠地运行在云端。下篇介绍ServiceComb的通信处理设计。 【参考】打造一个企业级应用的微服务开发框架（上）---从服务注册中心到服务管理中心 近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：微服务框架是否具备高可靠性，任何时间不能中断业务；微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，性能下降不会太多。本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架SeviceComb如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。下篇将详细介绍ServiceComb的通信处理。 ServiceComb通信处理详解1 整体介绍ServiceComb的底层通信框架依赖Vert.x.vertx标准工作模式为高性能的reactive模式，其工作方式如下图所示：13913图9 reactive模式工作方式业务逻辑直接在eventloop中执行，整个业务流程中没有线程切换，所有的等待逻辑都是异步的，只要有任务，则不会让线程停下来，充分、有效地利用系统资源。vertx生态中包含了业界常用各种组件的reactive封装，包括jdbc、zookeeper、各种mq等等。但是reactive模式对业务的要求相当高，业务主流程中不允许有任何的阻塞行为。因此，为了简化上层业务逻辑，方便开发人员的使用，在Vertx之上提供同步模式的开发接口还是必不可少的，例如： [*]各种安全加固的组件，只提供了同步工作模式，比如redis、zookeeper等等 [*]一些存量代码工作于同步模式，需要低成本迁移 [*]开发人员技能不足以控制reactive逻辑 所以ServiceComb底层基于vertx，但在vertx之上进行了进一步封装，同时支持reactive及同步模式。工作于Reactive模式时，利用Vertx原生的能力，不必做什么额外的优化，仅需要注意不要在业务代码中阻塞整个进程。而同步模式则会遭遇各种并发性能问题。，本文描述同步模式下的各种问题以及解决方案。RESTful流程中，连接由vertx管理，当前没有特别的优化，所以本文中，连接都是指highway流程中的tcp连接。 2 同步模式下的整体线程模型13914图10 同步模式下的整体线程模型 [*]一个微服务进程中，为transport创建了一个独立的vertx实例 [*]Eventloop是vertx中的网络、任务线程 [*]一个vertx实例默认的Eventloop数为：2 * Runtime.getRuntime().availableProcessors() 3 服务消费者端在服务消费者端，主要需要处理的问题是如何更加高效地把请求推送到服务提供者上去，然后拿到服务提供者的返回信息。所以在这一端我们主要关注“如何更高效的发送数据”这个话题。 3.1 单连接模型最简单的单连接模型13916图11 最简单的单连接模型 从模型图中，我们可以看到，所有的consumer线程，如果向同一个目标发送数据，必然产生资源竞争，此时实际的处理如下： [*]Connection.send内部直接调用Vertx的socket.write(buf)，是必然加锁互斥的。 这必然导致大量并发时，大多数consumer线程都无法及时地发送自己的数据。 [*]Socket.write内部会调用netty的channel.write，此时会判断出执行线程不是eventloop线程，所以会创建出一个任务并加入到eventloop任务队列中，如果eventloop线程当前在睡眠态，则立即唤醒eventloop线程，异步执行任务。 这导致频繁的任务下发及线程唤醒，无谓地增加cpu占用，降低性能。优化的单连接模型13917图12 优化的单连接模型 在优化模型中： [*]每个TcpClientConnection额外配备一个CAS消息队列 [*]Connection.send不再直接调用vertx的write方法，而是： 所有消息保存到CAS队列中，减少入队竞争 通过原子变量判定，只有入队前CAS队列为空，才向eventloop下发write任务，唤醒eventloop线程 在eventloop中处理write任务时，将多个请求数据包装为composite buffer，批量发送，减少进入os内核的次数，提高tcp发送效率。代码参见： https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/client/tcp/TcpClientConnection.java[code]io.servicecomb.foundation.vertx.client.tcp.TcpClientConnection.packageQueue io.servicecomb.foundation.vertx.client.tcp.TcpClientConnection.send(AbstractTcpClientPackage,long, TcpResponseCallback)[/code]https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/tcp/TcpConnection.java[code]io.servicecomb.foundation.vertx.tcp.TcpConnection.write(ByteBuf) io.servicecomb.foundation.vertx.tcp.TcpConnection.writeInContext()[/code]进行此项优化后，在同一环境下测试2组数据，可以看到性能有明显提升（不同硬件的测试环境，数据可能差异巨大，不具备比较意义）：TPSLatency(ms)CPUTPS提升比例时延提升比例ConsumerProducer(新-旧)/旧(旧-新)/新优化前819861.22290%290%77.31%43.61%优化后1453690.688270%270%表6 单连接模型优化前后性能对比3.2 多连接模型在单连接场景下进行相应的优化后，我们发现其实还有更多的优化空间。因为在大多数场景中，实际机器配置足够高，比如多核、万兆网络连接、网卡支持RSS特性等。此时，需要允许一对consumer与producer之间建立多条连接来充分发挥硬件的性能。13918图13 多连接模型 [*]允许配置多个eventloop线程 在microservice.yaml中进行以下配置：[code]cse: highway: client: thread-count: 线程数 server: thread-count: 线程数[/code] [*]Consumer线程与eventloop线程建立均衡的绑定关系，进一步降低consumer线程的竞争概率。 代码参见：https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/foundations/foundation-vertx/src/main/java/io/servicecomb/foundation/vertx/client/ClientPoolManager.java[code]io.servicecomb.foundation.vertx.client.ClientPoolManager.findThreadBindClientPool()[/code]优化后的性能对比：TPSLatency (ms)CPUTPS提升比例时延提升比例ConsumerProducer(新-旧)/旧(旧-新)/新简单单连接*105434420.9192305%1766%72.81%42.11%CAS单连接*109391170.5321960%1758%表7 多连接下线程模型优化前后性能对比 每请求大小为1KB，可以看到万兆网的带宽接近吃满了，可以充分利用硬件性能。(该测试环境，网卡支持RSS特性。)4 服务提供者端不同于服务消费者，服务提供者主要的工作模式就是等待消费者的请求，然后处理后返回应答的信息。所以在这一端，我们更加关注“如何高效的接收和处理数据”这件事情。同步模式下，业务逻辑和IO逻辑分开，且根据“隔离仓”原则，为了保证整个系统更加稳定和高效地运行，业务逻辑本身也需要在不同隔离的区域内运行。而这些区域，就是线程池。所以构建服务提供者，就需要对线程池进行精细的管理。下面是针对线程池的各种管理方式。4.1 单线程池(ThreadPoolExecutor)下图表示的是将业务逻辑用单独的线程池实现的方式。在这种方式下，IO仍然采用异步模式，所有接到的请求放入队列中等待处理。在同一个线程池内的线程消费这个队列并进行业务处理。13919图14 单线程池实现方式在这种方式下，有以下瓶颈点： [*]所有的eventloop向同一个BlockingQueue中提交任务 [*]线程池中所有线程从同一个BlockingQueue中抢任务执行 ServiceComb默认不使用这种线程池。4.2 多线程池(ThreadPoolExecutor)为规避线程池中Queue带来的瓶颈点，我们可以使用一个Executor将多个真正的Executor包起来。13920图15 多线程池实现方式 [*]Eventloop线程与线程池建立均衡的绑定关系，降低锁冲突概率 [*]相当于将线程分组，不同线程从不同Queue中抢任务，降低冲突概率 ServiceComb默认所有请求使用同一个线程池实例：io.servicecomb.core.executor.FixedThreadExecutorFixedThreadExecutor内部默认创建2个真正的线程池，每个池中有CPU数目的线程，可以通过配置修改默认值：[code]servicecomb: executor: default: group: 内部真正线程池的数目 thread-per-group: 每个线程池中的线程数[/code]代码参见：https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/core/src/main/java/io/servicecomb/core/executor/FixedThreadExecutor.java4.3 隔离仓业务接口的处理速度有快有慢，如果所有的请求统一在同一个Executor中进行处理，则可能每个线程都在处理慢速请求，导致其他请求在Queue中排队。此时，可以根据业务特征，事先做好规划，将不同的业务处理按照一定的方式进行分组，每个组用不同的线程池，以达到隔离的目的。13921图16 隔离仓 隔离仓的实现依托到ServiceComb灵活的线程池策略，具体在下一节进行描述。4.4 灵活的线程池策略ServiceComb微服务的概念模型如下：13922图17 ServiceComb微服务概念模型可以针对这3个层次进行线程池的配置，operation与线程池之间的对应关系，在启动阶段既完成绑定。operation与线程池之间的绑定按以下逻辑进行： [*]查看配置项cse.executors.Provider.[schemaId].[operationId]是否有值 如果有值，则将值作为beanId从spring中获取bean实例，该实例即是一个Executor 如果没有值，则继续尝试下一步 [*]使用相同的方式，查看配置项cse.executors.Provider.[schemaId]是否有值 [*]使用相同的方式，查看配置项cse.executors.default是否有值 [*]以”cse.executor.groupThreadPool”作为beanId，获取线程池（系统内置的FixedThreadExecutor） 代码参见：https://github.com/ServiceComb/ServiceComb-Java-Chassis/blob/master/core/src/main/java/io/servicecomb/core/executor/ExecutorManager.java 按以上策略，用户如果需要创建自定义的线程池，需要按以下步骤执行： [*]实现java.util.concurrent.Executor接口 [*]将实现类定义为一个bean [*]在microservice.yaml中将线程池与对应的业务进行绑定 4.5 线程池模型总结如上一节所述，在默认多线程池的基础上，CSE提供了更为灵活的线程池配置。“隔离仓”模式的核心价值是实现不同业务之间的相互隔离，从而让一个业务的故障不要影响其他业务。这一点在CSE中可以通过对线程池的配置实现。例如，可以为不同的operation配置各自独立的线程池。 另外，灵活性也带来了一定的危险性。要避免将线程池配置为前面提到的“单业务线程池”模式，从而为整个系统引入瓶颈点。 ServiceComb除了在华为云微服务引擎商用之外，也于2017年12月全票通过进入Apache孵化器。欢迎感兴趣的读者前往开源社区和我们讨论切磋，希望此文可以给正在进行微服务方案实施的读者们一些启发。