华为云技术私享会是华为云面向中小企业、创业公司的开发者、程序员分享技术精华的线下活动。华为云PaaS第一站于本月17日来到北京中关村，和大家分享PaaS产品微服务、中间件的云上风采。接下来第二站[云安全]将于本月24日在北京赛欧孵化中心登场。微服务作为一颗冉冉升起的新星，如今正逐渐成为一种主流的架构。云中间件，成就了电商平台的超级承载力，实现了系统快速水平扩展。实力现场：技术大咖面对面私享会开场，四位华为云PaaS资深架构师分别从不同角度讲述了微服务和云中间件的技术精华与产品特点。·开场惊喜：应用架构演进技术面对面-微服务和中间件华为云微服务架构师张琦从速度（业务上线）与安全（系统在一个可靠的状态下运行）切入，介绍了微服务在传统企业应用开发模式缺陷下，逐渐突显的重要性，以及构建微服务架构的应用系统——Chassis和Side-car。华为云微服务架构师张琦·经典环节 ：给我一杯咖啡的时间，玩转企业IT系统微服务化上云身着ServiveComb logoT恤的华为云微服务架构师郑扬勇介绍了微服务开源项目ServiceComb的来历、发展、子项目。ServiceComb作为一个功能完善的微服务框架，包括应用框架代码生成，服务注册发现、服务配置管理、服务监控、服务调用追踪、多通信协议支持等功能，为开发者提供端到端的应用DevOps体验。此外，还介绍了ServiceComb 中的Java Chassis架构，并进行现场演示。华为云微服务架构师郑扬勇·特别环节：基于Service Mesh实现非侵入式微服务方案演示华为云微服务架构师、文艺男神田晓亮从控制面、数据面讲解了最新研发的Mesher的各大优势，并分析了ServiceComb侵入式和Mesher非侵入式微服务的联系与区别，以及未来的发展趋势（两者结合），当然，现场演示如何使用Mesher也少不了。华为云微服务架构师田晓亮·有趣环节：基于分布式云中间件，15分钟实现海量数据的高可用架构演变幽默风趣中间件华为云架构师黄靖凯在此环节回顾了他的成长史——云中间件的成长史，介绍了华为电商云的架构和典型服务，以及如何使用华为云，快速搭建一个云上电商系统以及分布式缓存的服务（DCS）内容，并演示了“电商系统的分布式改造”。华为云架构师黄靖凯精彩互动：线上线下享不停除大咖分享外，本次私享会还给大家准备了神秘礼包、亲密交流等环节，无法来到现场的朋友也能通过线上直播参与进来。·神秘彩蛋：电商系统的分布式改造终环节，为粉丝们准备了专属的400元礼包，随后通过二维码扫描进入了华为云demo的界面。20分钟后，华为云资源购买模拟完毕；10分钟后，电商系统的应用系统部署(传统的单体应用)完毕；电商系统的分布式改造(基于分布式云中间件)难题也解决了….又快又顺畅！华为云技术私享会PaaS首站现场·现场问答：面对霸气外露的“技术巨星们”，热情的”粉丝们”不管是以往使用微服务或中间件产生的疑问，还是现场产生的新想法，都踊跃提出积极交流，现场气氛一片火热。·线上互动：来不了的“粉丝”也没有被忘记，线上直播同样如约而至，300+人次观看，互动区更是评论爆满…来日再约：我在赛欧孵化中心等你如果这一次你依然错过了，没关系！11月24日，下一场华为云技术私享会-如何做好云上安全将在丰台区赛欧孵化中心，5F咖啡举办，一起玩耍吧！本次私享产品免费中，登陆华为云官网即刻体验微服务引擎CSE：http://www.huaweicloud.com/product/cse.html分布式数据库中间件 DDM：http://www.huaweicloud.com/product/ddm.html分布式消息服务DMS：http://www.huaweicloud.com/product/dms.html

不知不觉来杭州已经6个年头了，杭州发生了翻天覆地的变化，眼瞅着滨江的房价从4000一平到40000一平。犹记得大学的时候，滨江还是鸟不拉屎的地方，学长学姐们被滨江的公司录取之后，还是一脸不屑，曾经看不起，现在攀不起。家底厚的人，凑足个首付，开始了以租养贷的生活。我作为一个家底不殷实，祖坟不发光的勤恳程序员，一直过着租房的生活，从最早的1100的小房子，到现在同样的房间租到2500，忍不住想聊聊这几年的换房血泪史。{:3_45:}第一家房子是刚毕业租的，房租1100，顶楼的小房间，楼高很低很压抑，但是毕竟收入不高，也就欣然接受了。现在回想那个时光，也是非常佩服自己能忍。房子是老小区， 6层高没有电梯，我不得不自己背着行李上上下下。{:2_28:}房子压抑，冬冷夏暖：冬天进门，冰冷的鬼气上蹿下跳；夏天进门，热浪的火气扑面而来……厕所不通风，房间靠马路吵吵吵。奈何房东人非常好，没事不瞎BB。我住了2年，终于在换工作之后也离开了这里。 第二个房子，户主把房子隔成了4户，我租了个简单的一室，阳台挨着隔壁的卫生间。所以隔壁租户卫生间常年扯着帘子，我晾晒好衣服，也是急急关门回房，尴尬的位置尴尬的生活，虽是邻里，认识都是多余。出租房里总是多事，对面的哥们有一晚电脑被盗了，半夜叫了警察，对我们也进行了盘问，个中辛酸，都在大家眼睛里。{:2_40:} 第三个房子的房东那叫一个嚣张，合同一满，恰逢出租屋整改，敲掉很多不合规矩的出租房，所以租客瞬间多起来，房子紧缺。眼看着市场大好，房东嚷着加钱，各种苛刻条件如狂风来袭。当时血气上涌的我毅然表示不租，房东就马上嚷着让我本周就搬走，说自己的房子随便高价就能转租，你临时找不到房子千万不要回来找我，不然价更高！{:2_33:}永远忘不了那几个搬家的日子，约了车，请了假，不好意思叫朋友的时候，只能自己楼上楼下攀爬，打包行李，满心疲惫。每一个辛苦搬家的日子，都是忍不住想流泪的日子。扪心自问：早已厌倦这种无处安身的日子。5287 作为一个远在外乡漂泊的人，面对出租房里有这么多的问题：1、搬家浪费时间，没有归属感（环境差的第1个房子）；2、无人监管（夜里失窃的第2个房子）；3、高峰期变数大（出租房紧缺时暴涨租金的第3个房子） ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！ 出租房里的辛酸因为没得选，因为资源有限，自身能力有限，只能屈就求全。但是同样是搬家，企业应用迁移上云，效果就温和多了！选择ServiceStage微服务云应用平台！ServiceStage微服务云应用平台帮助企业应用逐步迁移上云：1、业务分钟级部署（不会那么浪费时间）；2、弹性伸缩业务高可靠（不会动不动加价让你搬家）；3、多维度应用监控（小区有人管了）ServiceStage微服务云应用平台，让业务创新“快人一步” 人也好，应用也好，希望每一次迁移都不辛苦，希望我们都有自己的家。{:4_96:} 你会需要的更多介绍：【ServiceStage微服务云应用平台 】全13篇：从介绍到教程全汇总 5305

本帖最后由 李白云 于 2017-11-17 15:28 编辑感谢各位同学花费你宝贵的时间来到社区，希望你来了，能够在社区有所收获。 版主为了大家能够在社区更好地晃悠，写了一个简单的闲逛指南： 本社区包括五大板块：答疑求助| 干货分享| 教程攻略| 技术探讨| 活动专区| 如果你是带着对微服务技术或者微服务引擎产品的疑惑，那么你可以去在答疑求助板块里提问题，我们有一**帅气有才的专家会为你解答。 如果你想快速体验产品，那么可以前往教程攻略当中查看相关指导。 如果你想和大家分享你对微服务的一些观点和看法，可以前往技术探讨开始你的show。 如果你想了解微服务引擎在各大城市的精彩线下活动可以前往活动专区。 积极活跃才华横溢的同学{:3_62:}，社区现在正缺人手，欢迎你加入我们的社区运营哟！

本帖最后由 李白云 于 2017-12-11 14:15 编辑3个小时，能做什么？ 一部大片几局“农药”一场篮球一本好书...在这个碎片化的时代，如何最大化发挥时间的效能？ 在这个云计算的时代，如何掘金技术，收获价值？ 从现在开始 华为云技术私享会第二站：微服务与云中间件 全面启动！11月18日下午两点北京中关村3W咖啡与大牛们面对面私享海量技术、应用…私享他们的极客智慧 5039 5040 有兴趣的同学在微信手机客户端当中访问原文：https://open.weixin.qq.com/conne ... t=1#wechat_redirect

看了很多帖子，但是对哪些应用适合用在微服务上还是有困惑，希望可以得到回复，谢谢。

如果想开发好微服务还需要什么框架？能不能具体讲解下？

关于微服务的疑问：什么样的场景、应用适合微服务，什么东西不适合微服务？是否影响运行效率？

本帖最后由 云飞杨 于 2017-11-15 16:03 编辑前几天，“80后中年人” 的话题被重新提起，气哭了一大批“少男少女”。有人觉得自己只是个一百多斤的孩子；有人说确实人到中年，上有老下有小的生活很是艰辛，突然这么一提醒，仿佛担子更重了。 以下是他们的日常对话：4928 正当范仔四顾茫然犯愁之际，忽然瞥到闲置在角落的一个保温杯，只见红色LOGO下写着：4929 “华为云CSE微服务引擎，万能的微服务管理平台 —— 你人生的春天” （别搜了，非卖品） “不知道能不能带我找到第二春啊”范仔一边想着一边搜索华为云CSE，点开介绍页面。发现华为云推出的CSE专业服务企业级应用，包含了微服务SDK、一系列配套的开发工具和企业级微服务管理平台。4930 http://www.huaweicloud.com/product/cse.html 还免费！！！ 立即使用后，范仔越发欢喜 █ 易用好上手：节约开发时间的利器，基于华为云打通了微服务开发、构建和部署，版本升级分分钟搞定；并且微服务注册、通信和治理等基础能力齐全，到手就能用，早早下班不是梦 █ 安全可靠：拥有双重保障能力，认证鉴权、黑白名单等能力保障访问安全和负载均衡、熔断容错保障高可靠运行，简直就是程序猿的福音。 █ 遗留应用零改造：提供ServiceMesh非侵入式方案，支持多种开发语言，让公司的遗留应用也能零改造轻松上云，帮老板省钱so easy；还兼容主流开源社区SpringCloud，与业界生态紧密互通。 █开源开放促活力：微服务开发框架ServiceComb已独家开源（http://servicecomb.io/cn/），并接入开源社区github），求师问道无阻碍，代码写得更轻松。 这只不过是范仔通过华为云CSE解救加班群众的故事却道出了华为云CSE微服务引擎的宗旨让应用开发管理更高效，让客户&Boss都微笑

本帖最后由 云微观 于 2017-11-15 15:22 编辑前几天，“80后中年人” 的话题重新提起，气哭了一大批“少男少女”。有人觉得自己只是个一百多斤的孩子;有人说确实人到中年，上有老下有小的生活很是艰辛，突然这么一提醒，仿佛担子更重了。加班停不了>群的小伙伴范仔和我们哭诉：人到中年，压力真的很大，亲娘逼我找对象也就算了，老板还不放过我!应用开发本来就困难，天天加班到凌晨，他还说我们出现问题解决速度慢，完全不符合公司冲击宇宙500强的宏伟定位;而且版本更新周期长，在大版本升级时还得停机中断服务，害他损失几个亿……现在迫切需要找个安全可靠的平台解决这些问题，老架构已经不堪重负，一定要选择最先进的分布式架构，同时保证问题定位要快、修复要及时，语言协议要兼容，最重要的是便宜，把他失去的几个亿补回来!大家抓耳挠腮出主意，但都没有切实可行的办法。正当范仔四顾茫然犯愁之际，忽然瞥到闲置在角落里一个印着红色菊花的保温杯，想起这参加华为全联接大会的赠品，拿起保温杯，只见红色LOGO下写着一行“华为云CSE微服务引擎，一站式微服务管理平台——你人生的春天”。4911“不知道能不能带我找到第二春啊”范仔一边想着一边搜索华为云CSE，点开介绍页面。发现华为云推出的CSE专业服务企业级应用，包含了微服务SDK、一系列配套的开发工具和一站式微服务管理平台，现在还免费!果断点进了立即使用。试用中范仔走过了4步心路历程，越用越欢喜：49121)简单易用好上手：节约开发时间的利器，基于华为云打通了微服务开发、构建和部署，版本升级分分钟搞定;并且微服务注册、通信和治理等基础能力齐全，到手就能用，早早下班不是梦2)安全可靠更放心：拥有双重保障能力，认证鉴权、黑白名单等能力保障访问安全和负载均衡、熔断容错保障高可靠运行，简直就是程序猿的福音。3)遗留应用零改造：提供ServiceMesh非侵入式方案，支持多种开发语言，让公司的遗留应用也能零改造轻松上云，帮老板省钱so easy;还兼容主流开源社区SpringCloud，与业界生态紧密互通。4)开源开放促活力：微服务开发框架ServiceComb已独家开源(http://servicecomb.io/cn/)，并接入开源社区github)，求师问道无阻碍，代码写得更轻松。试用过后，范仔已抑制不住内心的激动，老板的要求达到不说，还能解放一起加班的难兄难弟们。于是欢天喜地去找老板汇报，准备说服老板早日用上CSE,让应用开发管理更高效，让大家过上好日子。华为微服务引擎CSE ：http://www.huaweicloud.com/product/cse.html开源社区ServiceComb：http://servicecomb.io/cn4913

点击下载ppt完整版【热门活动】寻找超级算法大师-挑战最优算法，赢取荣耀8X！跳转链接：https://bbs.huaweicloud.com/forum/thread-13282-1-1.html

Q: ServiceComb日志替换A: CSE java-chassis日志推荐方式是在启动的时候使用Log4jUtils.init()，直接使用推荐的Log4j来做日志管理，但是有些场景不想用log4j，比如想使用log4j2或者logback，下面以log4j2为例简单介绍下步骤：在代码里面不要使用Log4jUtils.init()；去掉log4j的配置文件（不删掉也没关系，因为不会使用）；exclude掉CSE框架引入的log4j，例如：<dependency> <groupId>io.servicecomb</groupId> <artifactId>provider-springmvc</artifactId> <exclusions> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency> Copy引入log4j2的依赖<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> </dependency> Copy如果没有版本依赖管理，还需要填写上版本号。加入log4j2的配置文件log4j2.xml，关于这个请查看官方说明，例如： <?xml version="1.0" encoding="UTF-8"?> <!--日志级别以及优先级排序: OFF > FATAL > ERROR > WARN > INFO > DEBUG > TRACE > ALL --> <!--Configuration后面的status，这个用于设置log4j2自身内部的信息输出，可以不设置，当设置成trace时，你会看到log4j2内部各种详细输出--> <!--monitorInterval：Log4j能够自动检测修改配置 文件和重新配置本身，设置间隔秒数--> <configuration status="WARN" monitorInterval="30"> <!--先定义所有的appender--> <appenders> <!--这个输出控制台的配置--> <console name="Console" target="SYSTEM_OUT"> <!--输出日志的格式--> <PatternLayout pattern="[%d{HH:mm:ss:SSS}] [%p] - %l - %m%n"/> </console> <!--文件会打印出所有信息，这个log每次运行程序会自动清空，由append属性决定，这个也挺有用的，适合临时测试用--> <File name="log" fileName="log/test.log" append="false"> <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %class{36} %L %M - %msg%xEx%n"/> </File> <!-- 这个会打印出所有的info及以下级别的信息，每次大小超过size，则这size大小的日志会自动存入按年份-月份建立的文件夹下面并进行压缩，作为存档--> <RollingFile name="RollingFileInfo" fileName="${sys:user.home}/logs/info.log" filePattern="${sys:user.home}/logs/$${date:yyyy-MM}/info-%d{yyyy-MM-dd}-%i.log"> <!--控制台只输出level及以上级别的信息（onMatch），其他的直接拒绝（onMismatch）--> <ThresholdFilter level="info" onMatch="ACCEPT" onMismatch="DENY"/> <PatternLayout pattern="[%d{HH:mm:ss:SSS}] [%p] - %l - %m%n"/> <Policies> <TimeBasedTriggeringPolicy/> <SizeBasedTriggeringPolicy size="100 MB"/> </Policies> </RollingFile> <RollingFile name="RollingFileWarn" fileName="${sys:user.home}/logs/warn.log" filePattern="${sys:user.home}/logs/$${date:yyyy-MM}/warn-%d{yyyy-MM-dd}-%i.log"> <ThresholdFilter level="warn" onMatch="ACCEPT" onMismatch="DENY"/> <PatternLayout pattern="[%d{HH:mm:ss:SSS}] [%p] - %l - %m%n"/> <Policies> <TimeBasedTriggeringPolicy/> <SizeBasedTriggeringPolicy size="100 MB"/> </Policies> <!-- DefaultRolloverStrategy属性如不设置，则默认为最多同一文件夹下7个文件，这里设置了20 --> <DefaultRolloverStrategy max="20"/> </RollingFile> <RollingFile name="RollingFileError" fileName="${sys:user.home}/logs/error.log" filePattern="${sys:user.home}/logs/$${date:yyyy-MM}/error-%d{yyyy-MM-dd}-%i.log"> <ThresholdFilter level="error" onMatch="ACCEPT" onMismatch="DENY"/> <PatternLayout pattern="[%d{HH:mm:ss:SSS}] [%p] - %l - %m%n"/> <Policies> <TimeBasedTriggeringPolicy/> <SizeBasedTriggeringPolicy size="100 MB"/> </Policies> </RollingFile> </appenders> <!--然后定义logger，只有定义了logger并引入的appender，appender才会生效--> <loggers> <!--过滤掉spring和mybatis的一些无用的DEBUG信息--> <logger name="org.springframework" level="INFO"></logger> <logger name="org.mybatis" level="INFO"></logger> <root level="all"> <appender-ref ref="Console"/> <appender-ref ref="RollingFileInfo"/> <appender-ref ref="RollingFileWarn"/> <appender-ref ref="RollingFileError"/> </root> </loggers> </configuration> Copy启动服务进行验证Q: netty版本问题A: netty3和netty4是完全不同的三方件，因为坐标跟package都不相同，所以可以共存，但是要注意小版本问题，小版本必须使用CSE的版本。Q: 服务超时设置A: 在微服务描述文件（microservice.yaml）中添加如下配置： cse: request: timeout: 30000 CopyQ: URL 地址就可以唯一定位，为什么要加上一个schema？A:schema 是用来匹配服务契约的，用来保证服务端和消费端契约兼容，每个契约需要一个唯一ID，在服务中心存储。schema映射到java的inte**ce概念，在consumer使用透明rpc模式开发时，可以找到是微服务里的哪个operation。schema之间的方法名是没有唯一性要求的。operation qualified name是治理的key，而URL 因为path参数的存在，没办法直接查找，而qualified name是不会变的。治理是不区分传输的，如果治理按URL 走，那么highway调进来时，还得根据参数反向构造出url，再来正则表达式匹配，太折腾了。http只是一种传输通道，还有别的传输通道不需要映射到URL的。Q: rest客户端调用的时候，实际上只带上了服务名和URL，并不需要指定schema id的， 而实际上根据这个URL也能找到具体契约的，所以指定schema id作用何在？A: 由于透明rpc是接口式调用，并没有URL，内部实际都归一化到operation来描述的，这样就可以结合schema id唯一定位到具体的请求处理中。Q: Transport是个什么概念？用来干什么的？A: transport负责编解码，以及传输。通信模型有rest和highway两种，highway对应的是私有协议，使用protobuf编码，rest用的是json。hightway和rest都是基于vertx做的，vertx是基于netty的。Q: 框架中引入了vertx会有什么好处？A: 启用vertx的标准工作模式更强大，不过对业务人员要求就有些高了，目前还没开放业务接口出来。vertx标准的reactive工作模式，要求业务代码中不能有任何的block wait,sleep，大循环，总之，不能停下来。做到这一点，可以用少很多的CPU，提供更多的服务。Q: 一个服务提供者里面会有多个 appid 和微服务吗？什么场景会出现这种情况？A: 会，这里表达的是一个merge的概念。microservice.yaml文件，可能同时存在于jar，磁盘，命令行参数指定这几个地方，此时他们按优先级合并，是用于增加灵活性的。在jar里的是默认值，在此之外，还有环境变量，命令行参数，配置中心覆盖，提供多层定制。Q: ServiceComb和服务中心是怎么交互的?A: 走rest，主要负责注册，取数据和心跳等；watch事件走websocket，watch事件是观察服务中心实例信息有没有变更。Q: 有类似dubbo那种治理中心吗？A: bizkeeper是一个handler，是治理的其中一个内容。治理可以通过handler扩展。Q: service path怎么理解？A: 每个微服务有一个servicePathManager，每一个schema将自己的path注册进去。Q: 这样浏览器能访问到吗？A: 可以，restful的URL路由，都是由service path搞定。Q: 契约生成时，需要强制带上版本号和语言吗？A: 契约是属于微服务的，微服务本来就有版本，但语言是不应该带上版本号的。应该契约要求与语言无关。契约“没有版本”，契约的版本体现在微服务上，实例能找到所属的微服务的版本，就能找到一个确定的契约。Q: ServiceRegistry里的设计代码和Eureka很类似？A: 我们第一个版本就是在Spring Cloud的基础上做的 后来随着发展发现不够用了才逐渐自己做的一套，所以的确是在充分参考Eureka后设计的。Q: 有些rpc是netty调用redis实现，比直接netty转发优势在哪里？A: 可能是想用redis解决订阅发布吧。但这样意义也不大，之前也尝试过这么用，但后来都改成ServiceComb了。Q: 如果同时引入了transport-rest-servlet和transport-rest-vertx的依赖，那么它怎么决定采用哪一个？A: 如果端口没被占用，就用vertx；如果被占用了，就用servlet。Q: qps流控设计时是出于什么场景考虑的？A: 限流有两个主要作用，第一通过给不同的消费者限流保证对一些重点服务的服务效果，第二防止雪崩效应。可根据服务的重要性来决定水管的粗细，ServiceComb是支持消费端限流和服务端限流两种限流方式的，消费端限流可以做到比较精细的控制。Q: 如果服务端是链式调用，即类似a->b->c，那设置了qps 流控会不会造成水管粗细不均的事情？A: 一般采取的模式是先测量再设置。qps设置最终是结合整体业务需求来进行调控的，而不是就单个节点来进行设置。

Q: swagger body参数类型定义错误，导致服务中心注册的内容没有类型信息现象描述:定义如下接口，将参数放到body传递 /testInherate: post: operationId: "testInherate" parameters: - in: "body" name: "xxxxx" required: false type: string responses: 200: description: "response of 200" schema: $ref: "#/definitions/ReponseImpl" Copy采用上面方式定义接口。在服务注册以后，从服务中心查询下来的接口type: string 丢失，变成了： /testInherate: post: operationId: "testInherate" parameters: - in: "body" name: "xxxxx" required: false responses: 200: description: "response of 200" schema: $ref: "#/definitions/ReponseImpl" Copy如果客户端没有放置swagger，还会报告如下异常： Caused by: java.lang.ClassFormatError: Method "testInherate" in class ? has illegal signature "CopyA：定义body参数的类型的时候，需要使用schema，不能直接使用type。 /testInherate: post: operationId: "testInherate" parameters: - in: "body" name: "request" required: false schema: type: string responses: 200: description: "response of 200" schema: $ref: "#/definitions/ReponseImpl" CopyQ: ServiceComb微服务框架服务调用是否使用长连接?A: http使用的是长连接（有超时时间），highway方式使用的是长连接（一直保持）。Q: 服务断连服务中心注册信息是否自动删除A: 服务中心心跳检测到服务实例不可用，只会移除服务实例信息，服务的静态数据不会移除。Q: 如果使用tomcat方式集成ServiceComb微服务框架，如何实现服务注册A: 如果使用cse sdk servlet方式（使用transport-rest-servlet依赖）制作为war包部署到tomcat，需要保证，服务描述文件（microservice.yaml）中rest端口配置和外置容器一致才能实现该服务的正确注册。否则无法感知tomcat开放端口。Q: 如果使用tomcat方式集成CSE微服务框架，服务注册的时候如何将war包部署的上下文注册到服务中心A: 发布服务接口的时候需要将war包部署的上下文（context）放在baseurl最前面，这样才能保证注册到服务中心的路径是完整的路径（包含了上下文）。实例： @path(/{context}/xxx) class ServiceA CopyQ: ServiceComb微服务框架如何实现数据多个微服务间透传A: 透传数据塞入： CseHttpEntity<xxxx.class> httpEntity = new CseHttpEntity<>(xxx); //透传内容 httpEntity.addContext("contextKey","contextValue"); ResponseEntity<String> responseEntity = RestTemplateBuilder.create().exchange("cse://springmvc/springmvchello/sayhello",HttpMethod.POST,httpEntity,String.class); Copy透传数据获取： @Override @RequestMapping(path="/sayhello",method = RequestMethod.POST) public String sayHello(@RequestBody Person person,InvocationContext context){ //透传数据获取 context.getContext(); return "Hello person " + person.getName(); } CopyQ: ServiceComb微服务框架服务如何自定义返回状态码?A: @Override @RequestMapping(path = "/sayhello",method = RequestMethod.POST) public String sayHello(@RequestBody Person person){ InvocationContext context = ContextUtils.getInvocationContext(); //自定义状态码 context.setStatus(Status.CREATED); return "Hello person "+person.getName(); } CopyQ: ServiceComb body Model部分暴露A: 一个接口对应的body对象中，可能有一些属性是内部的，不想开放出去，生成schema的时候不要带出去，使用： @ApiModelProperty(hidden = true) CopyQ: ServiceComb框架获取远端consumer的地址A: 如果使用http rest方式（使用transport-rest-vertx依赖）可以用下面这种方式获取： AbstractProducerContextArgMapper httpRequestCreator = (AbstractProducerContextArgMapper)invocation.getHandlerContext().get(RestConst.HTTP_REQUEST_CREATOR); if(httpRequestCreator != null){ HttpServletRequest req = (HttpServletRequest)httpRequestCreator.createContextArg(invocation); System.out.println(req.getRemoteHost()); } Copy实际场景是拿最外层的地址，所以应该是LB传入到edgeservice，edgeService再放到context外下传递。Q: ServiceComb不支持泛型A: 明确不支持，需要修改接口，接口修改后需要修改版本号，以免consumer还是使用旧的版本。Q: ServiceComb对handler描述A: consumer默认的handler是simpleLB，没有配置的时候handler链会使用这个，如果配置了handler，里面一定要包含lb的handler，否则调用报错，需要在文档里面进行说明。

本帖最后由 云飞杨 于 2017-11-14 10:30 编辑在学习一门新技术的时候，大家难免要通过搜索引擎、技术书籍、视频等渠道获取相关技术知识，为了让大家在微服务江湖当中能够游刃有余，快速上车，斑竹特意收集了大牛们学习微服务时阅读的资料，也欢迎各位同学跟帖分享自己的学习资料。 （列表持续更新中） 文章/书作者内容简介链接适合人群微服务（博客）James Lewis、Martin Fowler/（中文译者）伍斌微服务的开山鼻祖之作1）“微服务”原文链接：http://martinfowler.com/articles/microservices.html 2）“微服务”译文链接：http://mp.weixin.qq.com/s?__biz= ... e044fe6a387a1cc3#rd］ 涉世未深的小青年微服务资源指南（博客）Martin Fowler老马同学收集的微服务资源，值得一看http://martinfowler.com/microservices/有点内功基础，想要继续深入的同学微服务架构在Netflix的应用：架构设计的经验教训（博客）Cockcroft微服务架构设计的5个最佳实践http://blog.csdn.net/goodraincloud/article/details/50855643功力颇深的门派骨干Building Microservice/微服务设计Sam Newman从单体到微服务构建全流程（技术，工具，组织）支持正版，请大家自行购买书籍哦~~老少皆宜，居家旅行必备微服务架构和实践王磊如何从零开始构建一个微服务支持正版，请大家自行购买书籍哦~~老少皆宜，居家旅行必备SpringBoot揭秘-快速构建微服务体系王福强讲述了SpringBoot微框架的设计理念和原理支持正版，请大家自行购买书籍哦~~想要了解多个门派心法的同学可以阅读下Consumer-Driven Contracts（博客）Martin Fowler快速了解消费者驱动契约测试http://martinfowler.com/articles/consumerDrivenContracts.html打算在微服务测试大展身手的有为青年领域驱动设计（Domain-Driven Design, DDD）中的“限界上下文”（Bounded Context）（博客）Martin Fowler微服务各个边界的划分，DDD与Micro Service的理念是天然融合的，BC就是驱动出Domain Service的最佳起点。http://martinfowler.com/bliki/BoundedContext.html专业的微服务设计丛书，架构师的最爱哦领域驱动设计Eric Evans/埃文斯深入理解DDD支持正版，请大家自行购买书籍哦~~在华山论剑前，闭关修炼可携带的书籍实现领域驱动设计Vaughn Vernon深入理解DDD支持正版，请大家自行购买书籍哦~~在华山论剑前，闭关修炼可携带的书籍12-Factor（博客）Adam Wiggins适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序的理论https://12factor.net/任何SaaS应用的开发人员，部署和管理此类应用的运维工程师。Release It!Michael T. Nygard如何保证大量服务交互时候的稳定性支持正版，请大家自行购买书籍哦~~打算在微服务部署大展身手的有为青年RESTful Web Services CookBookSubbu Al**raju了解怎样设计一个好的rest服务。支持正版，请大家自行购买书籍哦~~欲潜心修炼一个通信架构风格的编程老手

本帖最后由 李白云 于 2017-12-16 22:26 编辑系列视频链接： https://portal.huaweicloud.com/videos/type_397ba2de1fc111e783e4e0247f00a8ce_tag_ab82a668c2ce11e7b8317ca23e93a891 开发第一个微服务： https://portal.huaweicloud.com/videos/fd482f380077427ca32972b8e322ad80 微服务治理之负载均衡： https://portal.huaweicloud.com/videos/5c28b10f85914977917ed4cfea08b342 微服务治理之限流： https://portal.huaweicloud.com/videos/154f105aaede410b8e39048c20e94b38

本帖最后由 李白云 于 2017-11-6 21:29 编辑原文链接：https://mp.weixin.qq.com/s/fbUX0YOVvs0Six_HLFCEhw 越来越多的企业正在加速业务的数字化转型，而随着代码库的膨胀、逻辑复杂度的增加，开发团队的脚步越来越沉重，同时难免要经历大量试错，这就要求IT系统具备敏捷灵活、低成本的特点。 如何利用微服务跑得更快，又不至于被繁杂的分布式系统管理工作所绊倒？ 华为云重磅推出华为云微服务引擎(Cloud Service Engine，简称CSE)业界首个商用的企业级微服务应用管理平台为企业应用微服务化提供一站式解决方案 化大为小，化繁为简 华为云此次推出的微服务引擎包含了微服务SDK、一系列的开发工具以及一站式微服务应用管理平台，同时还有专业的微服务解决方案团队，提供一站式解决方案支持，让企业纵享微服务带来的优点，无需关注背后的技术复杂性。 华为云微服务引擎架构图CSE五大核心优势1 低门槛 [*]微服务框架开箱即用 [*]微服务流水线一键式构建、部署和上线 2 零改造 [*]提供ServiceMesh非侵入式方案，让遗留应用也能轻松上云 [*]兼容SpringCloud主流开源社区，与业界生态能力互通 3 高可靠 [*]三十年电信行业高性能低时延应用经验积累 [*]经历华为终端云亿级用户，十亿级请求量考验 4 专业服务 [*]20+行业ISV合作伙伴 [*]30+微服务专业高级咨询师 5 开源开放 [*]开源微服务框架ServiceComb [*]活力无限的开源社区 CSE使能企业云化四大场景 1、新应用开发 开发者可通过平台一键式框架代码生成微服务应用，在本地开发时，开发者可使用本地服务注册中心、调试工具以及丰富的开发样例代码来实现快速开发。统一化和可以自动生成的契约解决分布式系统开发的复杂性。 2、遗留应用接入 |黑科技ServiceMesh|，支持多种开发语言的遗留应用0改造，低成本接入微服务治理，让遗留应用也能享受微服务治理能力。 3、持续集成 微服务流水线，一键跑通微服务代码编译、构建、部署和测试，实现业务小时级上线，同时该流程也支持企业自定义开发流程。 4、微服务治理 丰富的治理功能（自动负载均衡、自动容错、降级、限流等），支持微服务接口级SLA指标（吞吐量、时延、成功率）实时（秒级）监控和治理，保障应用运行不断服、更安全。 微服务的实施注定不会是一个简单的过程，企业用户需要根据自己的业务、发展阶段，选择适合的平台、工具、策略去实施微服务。选择一个完善的微服务平台，能够帮助企业发挥微服务的最大价值，选择一个开放的微服务平台，能够帮助企业构建微服务生态圈。 说好的免费呢？ 免费期限：2018年3月31日前 犹豫不决？我们有华为云社区微服务引擎论坛，欢迎您与社区里的大咖小粉探讨人生 还是犹豫不决？我们有… 11月7日 华为云中国行成都站微服务引擎架构师与你面对面探讨CSE设计思想 11月9日 西安程序员节大咖为你现场讲述新出炉热腾腾的微服务引擎 犹豫什么呢？我们勇敢地提出免费，就是为了让您不再犹豫