微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。微服务特点：1.服务组件化每个服务独立开发、部署，有效避免一个服务的修改引起整个系统重新部署。2.技术栈灵活约定通信方式，使得服务本身功能实现对技术要求不再那么敏感。类比联邦制国家。3. 独立部署每个微服务独立部署，并行开发，这样就加快部署速度，并且方便扩展。4.扩展性强每个微服务可以部署多个，并且方便提供负载均衡能力。5.独立数据每个微服务有自己独立的基本组件，例如数据库、缓存等。微服务存在以下不足：1.增加了服务之间的沟通成本；2.为保证数据一致性，增加了数据处理难度；3.增加了运维人员学习成本；4.微服务内部架构复杂性，增加了部署、运维管理的难度；

【功能模块】【操作步骤&问题现象】1、微服务引用的这两个包最终一个引用了validation-api的jar一个依赖了jakarta.validation-api-2.0.2，两个包冲突，怎么办2、【截图信息】【日志信息】（可选，上传日志内容或者附件）Caused by: org.springframework.beans.factory.BeanCreationException Error creating bean with name 'parameterValidatorFilter' defined in URL [jar:file:/usr/local/tomcat/webapps/ROOT/WEB-INF/lib/java-chassis-core-2.3.2.jar!/org/apache/servicecomb/core/filter/impl/ParameterValidatorFilter.class]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: javax.validation.BootstrapConfiguration.getClockProviderClassName()Ljava/lang/String;

【摘要】 十年磨一剑，云原生从最初的默默无闻到企业数字化转型的核心支撑，华为云作为CNCF的创始成员，一直在为社区贡献力量。随着技术和业务的演进，云原生2．0时代的新价值——“云上内生的云能力”成企业所需，看华为云云原生基础设施如何开启云原生2．0时代。文章简介什么是云原生都0202年了，如果你还不懂云原生，那真的out了。带你读懂容器技术，“容器”和“虚拟机”别再分不清容器这个词，当你第一眼看它或许脑子里是这东西：瓶瓶罐罐、装水、装其他东西的玩意。不管是什么，总的来说，容器给人第一印象就是——“装”。一文读懂k8s多集群技术发展史 一文带你了解Kubernetes多集群技术发展的历史、现状与未来。浅谈服务化和微服务化微服务是近期非常热门的话题，芸芸众生言必谈微服务。伯克利：serverless是下一代计算范式Serverless技术正是云厂商的基于规模经济的一个选择。Service Mesh：下一代微服务？微服务方兴未艾如火如荼之际，在 Spring Cloud 等经典框架之外，Service Mesh 技术正在悄然兴起。云原生系列技术：DevOps技术云计算和容器技术的快速普及，DevOps越来越被重视，甚至成为保证公司生产力的最佳之选。详解华为云容器全新解决方案华为云新一代容器基础设施“军舰”，来了！大数据容器化，头部玩家尝到了甜头？大数据容器化，大势所趋。头部玩家在进行大数据容器化后，尝到了甜头。从Vessel到二代裸金属容器，云原生新一波技术浪潮涌向何处云原生大势，深度解读华为云四大容器解决方案如何加速技术产业融合。云原生2.0时代：华为云开启应用定义基础设施新时代云原生以“应用使能”+“混合云”为核心，帮助企业本地部署与云端融合，打造企业急迫需要的混合云架构。为什么说容器的崛起预示着云原生时代到来？说到云原生，我们就不得不先了解一下容器技术。【容器】容器多云/混合云，云时代灾备新利器华为容器多云/混合云解决方案基于社区的集群联邦技术，提供了跨云的多集群统一管理、应用在多集群的统一部署和流量分发，并可以结合Istio技术，实现应用流量的全局治理。【KubeEdge】解读KubeEdge：云原生的边缘计算平台KubeEdge即Kube+Edge，顾名思义就是依托K8S的容器编排和调度能力，实现云边协同、计算下沉、海量设备的平滑接入。【Istio】万字解读:Service   Mesh服务网格新生代--Istio一文带你了解关于Istio技术的介绍、架构和展望。【Volcano】Volcano火山：容器与批量计算的碰撞 Volcano是基于K8s构建的一个通用批量计算系统，弥补了K8s在“高性能应用”方面的不足，支持TensorFlow、Spark、MindSpore等多个领域框架，帮助用户通过K8s构建统一的容器平台。【鲲鹏容器】华为云鲲鹏容器发布，极致释放多元算力在云+AI+5G的时代，昇腾+鲲鹏是企业创新的最佳算力选择。【AI容器】华为云AI容器：零基础搭建AI计算平台，提升计算效率 50%华为云 AI 容器为客户提供更高性价比算力，更简化了平台运维，提升 AI 计算效率 50%，加速 AI 计算在各行业的落地和发展。【裸金属容器】华为云重磅发布全球首个双零损耗裸金属容器 全球独家双零损耗裸金属容器——华为云第二代裸金属容器，首次在业内实现资源和性能的零损耗，让容器全面释放裸金属服务器的潜力，加速云原生创新升级。【裸金属容器】华为云第二代裸金属容器：应对海量并发的网络黑科技因突发流量触发业务扩容，以前是扩容虚机速度慢，现在大部分互联网平台都使用容器了，为什么扩容速度有些时候还是跟不上流量增长的节奏？【数据库】云原生数据库三驾马车之TaurusDBTaurus其设计思想是Log-as-database以最小化网络IO，采用计算存储分离的架构。【DevCloud】华为云DevCloud,云原生架构下的DevOps实践云原生架构与DevOps的落地与转型是一个量变到质变过程。【云容器引擎】带你了解云容器引擎CCE的权限管理借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序，快速高效的将微服务部署在云端。【容器】容器化之路：谁偷走了我的构建时间 什么是镜像？什么是镜像构建？什么是storage-driver？【Docker网络】《跟唐老师学习云网络》   - Docker网络实现带你详细理解Docker容器是如何实现Docker网络，以及解析一个容器是如何与本机、本机中的容器、其他Host、其他Host中的容器 等场景下分别是如何进行通信的详细原理。【Kubernetes】盘点Kubernetes网络问题的4种解决方案现在的开源世界里，有很多开源组件可以帮助我们打通Docker容器和容器之间的网络，实现K8s要求的网络模型。当然每种方案都有自己适合的场景，我们要根据自己的实际需要进行选择。【云容器引擎】微服务应用在CCE上的初探借助云容器引擎，在华为云上轻松部署、管理和扩展容器化应用程序，来为企业释放更多精力，CCE提供一整套完整的最佳容器解决方案，赋能企业专注业务开发。【Kubernetes】企业落地Kubernetes的问题与对策随着Kubernetes的全面成熟与大规模应用，如何落地Kubernetes是企业实施云战略需要考虑的迫切问题。【微服务】如何应对企业级微服务开发？最优解在这里…从服务管理中心、通信处理两个模块来介绍华为开源微服务框架 SeviceComb 如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。【Service】在K8S大规模场景下Service性能如何优化？ K8s 原生的 Service 负载均衡基于 Iptables 实现，其规则链会随 Service 的数量呈线性增长，在大规模场景下对 Service 性能影响严重。【安全容器】容器与虚拟化的结合：浅谈“安全容器”技术发展趋势无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。【Kubernetes】Kubernetes的拐点助推器：左手开源，右手边缘计算据2020边缘计算状态报告显示，到2022年，75%的数据将通过边缘分析和处理。这种数据处理的流动性，将伴随有4大边缘技术演进方向。本合集为《大厂内参》005期，欢迎大家持续关注。大厂内参根据开发者普遍关注的热门技术领域，汇编实践精华内容。从业务场景选型，应用案例分析，到前瞻趋势预测。以专题的形式，深度解读华为云核心技术，分享一线工程师的实战经验。【第一期】敏捷&Devops：80+篇实践干货分享，深度解读敏捷&DevOps如何革新软件开发【第二期】数据库：从数据库科普到核心技术解读、上云案例分享，全方位剖析云数据库【第三期】云服务器：选型解读+案例分享：云服务器“软硬技术”全公开【第四期】人工智能：海量实战经验教你零门槛进场AI开发，无成本负担玩转AI应用【第五期】云原生：读懂云原生2.0，看它如何重塑业务开发架构【第六期】云安全：Get防范云安全的必杀技，学会构建云上完整安全体系【第七期】物联网：“端边云”IoT全栈技术大揭秘，开发实战指南带你轻松上手IoT【第八期】数据仓库：8大场景系列玩转数仓运维，做个不秃头的DBA

尊敬的微认证客户：您好！因产品功能调整，华为云学院于2021年6月24日对《微服务网站性能测试》微认证的课程及实验进行下线优化，预计将于2021年7月23日重新上线，届时请您关注。为此，我们将采取以下措施：1．对于已购买该微认证并通过考试领取证书的客户，原证书在证书有效期内仍有效，并与课程优化后的证书拥有同等效力；2．对于已购买该微认证但未通过考试且仍有考试机会的客户，可在重新上线后进行新课程学习、实验，参加考试并领取证书；3．对于已购买该微认证但未完成实验操作的客户，如您在2021年6月24日前，自购买日期起在30天内（代金劵有效）未进行实验操作，华为云学院将于微认证优化重新上线后为您另行发放代金券，可用于优化后的微认证实验操作，新代金券自发放之日起30天内有效，请在有效期内使用。如您有任何问题，可随时通过工单或者服务热线（+86-4000-955-988 ）与我们联系。感谢您对华为云微认证的支持！ 发布日期：2021年6月24日

Dubbo和CSE底层都使用了Spring的依赖注入和bean管理系统，所以使用Dubbo的服务迁移到华为云微服务引擎CSE的工作量较小， 主要改动在依赖和配置方面。本示例的完整代码已放在GitHub上，其中目录dubbo-demo是原始的Dubbo DEMO，目录dubbo-demo-servicecomb是改造后的可直接运行于华为云CSE的DEMO。1、管理依赖：/dubbo-demo/pom.xml在主项目pom里的dependencyManagement中增加如下配置来管理CSE包依赖，子项目就不需要指定CSE版本号。  <dependencyManagement>    <dependencies>      <dependency>        <groupId>com.huawei.paas.cse</groupId>        <artifactId>cse-dependency</artifactId>        <version>2.3.9</version>        <type>pom</type>        <scope>import</scope>      </dependency>    </dependencies>  </dependencyManagement>注意，maven的settings需添加cse的mirror才能正常下载到cse的相关依赖包：    <mirror>      <id>nexus-cse</id>      <mirrorOf>*</mirrorOf>      <name>cse nexus</name>      <url>http://maven.huaweicse.com/nexus/content/groups/public</url>    </mirror>2、服务提供方：dubbo-demo-provider2.1、替换依赖：/dubbo-demo-provider/pom.xml将对Dubbo的依赖替换为对CSE的依赖pom.xmlDubbo        <dependency>            <groupId>com.alibaba</groupId>            <artifactId>dubbo</artifactId>            <version>2.5.7</version>        </dependency>CSE        <dependency>            <groupId>com.huawei.paas.cse</groupId>            <artifactId>cse-solution-service-engine</artifactId>        </dependency>2.2、通过添加标签的方式发布服务接口：DemoServiceImplDubbopublic class DemoServiceImpl implements DemoService {    ......}CSE@RpcSchema(schemaId = "providerSchema")public class DemoServiceImpl implements DemoService {    ......}2.3、修改配置：/dubbo-demo-provider/src/main/resources删除：/dubbo-demo-provider/src/main/resources/META-INF/spring/dubbo-demo-provider.xml新增：/dubbo-demo-provider/src/main/resources/META-INF/spring/demo.bean.xml<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"    xmlns:util="http://www.springframework.org/schema/util" xmlns:cse="http://www.huawei.com/schema/paas/cse/pojo"    xmlns:context="http://www.springframework.org/schema/context"    xsi:schemaLocation="        http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">      <context:component-scan base-package="com.alibaba.dubbo.demo" /></beans>新增：/dubbo-demo-provider/src/main/resources/microservice.yamlAPPLICATION_ID: dubbo_servicecombservice_description:  name: provider  version: 0.0.1cse:  service:    registry:      address: https://cse.cn-north-1.myhuaweicloud.com:443  rest:    address: 0.0.0.0:8082  credentials:    accessKey: 替换为华为云IAM账号AK（如何获取AK/SK）    secretKey: 替换为华为云IAM账号SK    akskCustomCipher: default    project: cn-north-12.4、修改提供方启动入口Dubbopublic class Provider {    public static void main(String[] args) throws Exception {        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"META-INF/spring/dubbo-demo-provider.xml"});        context.start();        System.in.read(); // 按任意键退出    }}CSEpublic class Provider {    public static void main(String[] args) throws Exception {        Log4jUtils.init();        BeanUtils.init();    }}3、服务消费方：dubbo-demo-consumer3.1、替换依赖：/dubbo-demo-consumer/pom.xml将对Dubbo的依赖替换为对CSE的依赖Dubbo        <dependency>            <groupId>com.alibaba</groupId>            <artifactId>dubbo</artifactId>            <version>2.5.7</version>        </dependency>CSE        <dependency>            <groupId>com.huawei.paas.cse</groupId>            <artifactId>cse-solution-service-engine</artifactId>        </dependency>3.2、修改消费方启动入口Dubbopublic class Consumer {    public static void main(String[] args) {        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"META-INF/spring/dubbo-demo-consumer.xml"});        context.start();        DemoService demoService = (DemoService) context.getBean("demoService");         String hello = demoService.sayHello("world");         System.out.println(hello);     }}CSEimport org.springframework.stereotype.Component;@Componentpublic class Consumer {    @RpcReference(microserviceName="provider", schemaId="providerSchema")    private static DemoService demoService;    public static void main(String[] args) throws Exception {        Log4jUtils.init();        BeanUtils.init();        String hello = demoService.sayHello("world");         System.out.println(hello);     }}3.3、修改配置：/dubbo-demo-comsumer/src/main/resources删除：/dubbo-demo-consumer/src/main/resources/META-INF/spring/dubbo-demo-consumer.xml新增：/dubbo-demo-consumer/src/main/resources/META-INF/spring/demo.bean.xml<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"    xmlns:util="http://www.springframework.org/schema/util" xmlns:cse="http://www.huawei.com/schema/paas/cse/pojo"    xmlns:context="http://www.springframework.org/schema/context"    xsi:schemaLocation="        http://www.springframework.org/schema/beans classpath:org/springframework/beans/factory/xml/spring-beans-3.0.xsd        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">      <context:component-scan base-package="com.alibaba.dubbo.demo" /></beans>新增：/dubbo-demo-consumer/src/main/resources/microservice.yamlAPPLICATION_ID: dubbo_servicecombservice_description:  name: consumer  version: 0.0.1cse:  service:    registry:      address: https://cse.cn-north-1.myhuaweicloud.com:443  rest:    address: 0.0.0.0:8084  credentials:    accessKey: 替换为华为云IAM账号AK（如何获取AK/SK）    secretKey: 替换为华为云IAM账号SK    akskCustomCipher: default    project: cn-north-14、验证：先启动Provider，再启动Consumer4.1、进入华为云微服务引擎CSE控制台：微服务管理>服务治理>dubbo_servicecomb，看到如下服务调用关系：4.2、进入Consumer的输出控制台，能看到输出：Hello world————————————————文章来源: blog.csdn.net，作者：looook原文链接：https://blog.csdn.net/looook/article/details/80312804

如果你的组织想要采用微服务，那么就需要了解领域驱动设计，事件驱动架构，核心域，子域，有界上下文，反腐层等等，以正确地拆分你的业务逻辑（Business Space）并将其与微服务体系结构（Code Space）映射，这样你就可以获得微服务的好处。我将在本文中对它们进行总结，并为你在组织中拆分微服务时提供一些指导。微服务拆分的10条规范1.使用有界上下文：使用有界上下文，我们分离数据模型，抽象业务中的共性。每个有界上下文都有自己的业务逻辑。在进行微服务拆分之前，首先要做的是缩小产品经理与开发人员之间的距离，产品经理可能不了解技术术语，技术团队可能不了解技术术语在业务方面的重要性。他们就像一个葡萄牙语人士与一位英语人士交谈：没有人理解彼此的信息。因此，为了弥补差距，我们需要采取以下步骤：开发人员与产品经理需要讨论：“业务目标是什么？”。“特定功能中的主要角色是什么？” “他们在定义功能时使用了哪些术语？” 在每个步骤上，都要提出更多问题，直到双方达成一致。每个上下文中每个域名实体名称都要是清晰的。为每种上下文定义一种通用语言，以便业务团队和技术团队在交流时可以使用一种通用语言进行交流。从一个粗粒度的有界上下文开始。2.确定核心域并保持竞争优势：核心域是为你的业务带来收益的领域。对于在线购物而言，购物车模块是核心领域，它为从企业到消费者（B2C）提供了平台。了解你的核心模块，并思考如何改进竞争对手没有的功能。任何自动化或创新都会提高优势并增加你的收入，因此请注意，要在核心领域进行研发和投资，以保持竞争优势。3.对通用域进行成本优化：通用域就是该领域中每个企业所共有的领域，并且不同的第三方厂商已经提供了解决方案。像你的信息通知模块或广告活动模块，建议不要花钱来重新发明轮子，最好以便宜的价格采用第三方解决方案。4.考虑支持领域：核心域需要支持域的帮助来丰富自身功能，甚至在某些情况下，支持域也可以带来收益，并且将来有可能成为核心域。例如，在购物车域中，库存管理是支持领域，但投资研发-识别客户订单最近库存位置的算法，对降低运输成本也很重要。5.引入反腐层：反腐层（Anti-corruption layer，简称 ACL）介于新应用和旧应用之间，用于确保新应用的设计不受老应用的限制。是一种在不同应用间转换的机制。创建一个反腐层，以根据客户端自己的域模型为客户提供功能。该层通过其现有接口与另一个系统进行通信，几乎不需要对其进行任何修改。因此，反腐层隔离不仅是为了保护你的系统免受异常代码的侵害，还在于分离不同的域并确保它们在将来保持分离。反腐层是将一个域映射到另一个域，这样使用第二个域的服务就不必被第一个域的概念“破坏”。实际上，我们经常遇到基于大型机或任何其他语言构建的旧系统，但无法拆分该系统，并且还需要使用旧应用的数据。因此，在旧应用和微服务通信之间创建反腐层是一个好主意。还要考虑通用领域，因为他们是不受开发团队控制的任何外部系统(第三方系统)，因此也需要引入一个反腐层，该层将微服务与外部AP隔离开来，充当微服务和第三方之间的翻译者。它还可以帮助你将来采用任何第三方库。6.识别数据通信模式：一旦基于功能拆分了微服务，并且每个核心服务封装了它们自己的数据库，接下来就要考虑不同微服务间是如何通信的？是同步的？还是异步的？例如，对于一些系统，用户可以执行部分功能并创建中间状态，另一个系统对中间状态采取措施并回调或通知用户。7.引入事件驱动架构（EDA）：在实际的应用程序中，你的业务案例具有复杂的工作流，并且根据数据的状态在工作流上具有许多分支。如果你考虑通过Rest API公开所有内容，则会看到它创建了一个复杂的通信网络。因此，我们需要一个干净的架构，其中每个微服务都可以独立运行而不会产生耦合，这里事件驱动的架构起着至关重要的作用，每个事件都包裹着状态的变化，并且微服务遵循发布订阅(pub/sub) 模型，因此一个微服务会发布以事件的形式包装的数据，其他微服务会侦听该事件。由于事件是不可变的，因此它也保存实体或聚合器的历史记录。8.使API简洁明了：在微服务中，在发布API时，请确保你的API不发布内部状态。发布API是一种使其他服务可以获取足够的信息以继续其流程的方式，因此要虑封装和网络调用，不应多次返回以获取派生信息。还要考虑事件，应该发布哪些事件以及哪些事件必须保留在内部。也许你可以发布一个粗粒度事件，而不是发布一个个内部的小事件。例如，你有地址更改事件和个人信息更改事件。最好是发布一个名为CustomerUpdateEvent的粗粒度事件，而不是提供两个独立的事件。9.将相关的微服务合并为更大的服务：拆分之后，当需要添加或更新功能时，你会遇到一些微服务总是一起变化的情况。这时候，你应该知道你已经以错误的方式拆分了它。它们一定不能被隔离到一个小型服务中，它们是同一逻辑单元的一部分。因此，将它们合并为一个服务是明智的，将减少不必要的网络通信。10. 引入无缝开发支持工具：微服务不是免费的午餐。如果你采用微服务，那么首先要做好准备，因为微服务是分布式的，因此要投资一些软件工具，以此来扩展弹性和提高可用性，并缩短产品投产时间，帮助尽早发现故障等。因此，请花钱在CI / CD流水线上，采用云基础架构，使用跟踪工具，使用日志聚合器来搜索日志，使用混沌工程测试你的系统，等等。结论拆分微服务时，以上几点是必要的。我将针对每个主题写一篇文章，介绍它们如何在采用微服务体系结构中发挥关键作用。另外，我想听听你在拆分微服务时所面临的挑战。译文链接: https://dzone.com/articles/10-commandments-on-microservice-decomposition转载https://www.kubernetes.org.cn/8994.html

什么是微服务：微服务是一种用于构建应用的架构方案。微服务架构与传统的单体式方案不一样，它可将应用拆分成多个核心功能。每个功能都被称为是一项服务，可以单独构建和部署，这意味着各项服务在工作（出现问题）时不会相互影响。

[ERROR][MapServiceRegistryClient.java-212][Service Center Task [java.util.concurrent.ThreadPoolExecutor$Worker@553f3655[State = -1, empty queue][85]]][]-register schema cn_dev_default#CDPSolutionService#MICROSERVICE#CDPDatasetService#alliance_cdp_cluster_dev#1.0.0.102/DataflowController fail.com.huawei.nuwa.map.support.servicecomb.client.MapServiceRegistryClientustomStackTrace com.huawei.nuwa.map.api.exception.InvalidParamException: {"code":400,"error":"schemaId is not belong to the service"}    at com.huawei.nuwa.map.client.RestApiClient.translateException(RestApiClient.java:160) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.RestApiClient.restApi(RestApiClient.java:76) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.NuwaMapClient.restApi(NuwaMapClient.java:467) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.NuwaMapClient.registerMicroServiceSchema(NuwaMapClient.java:407) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.MicroServiceClient.registerMicroServiceSchema(MicroServiceClient.java:133) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.support.servicecomb.client.MapServiceRegistryClient.registerSchema(MapServiceRegistryClient.java:208) [nuwa-cloudmap-registry-servicecomb-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.support.servicecomb.client.DelegatedServiceRegistryClient.registerSchema(DelegatedServiceRegistryClient.java:202) [nuwa-cloudmap-registry-servicecomb-1.0.1.105.jar!/:?]    at org.apache.servicecomb.serviceregistry.task.MicroserviceRegisterTask.registerSingleSchema(MicroserviceRegisterTask.java:368) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.MicroserviceRegisterTask.registerNewSchema(MicroserviceRegisterTask.java:222) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.MicroserviceRegisterTask.registerSchema(MicroserviceRegisterTask.java:200) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.MicroserviceRegisterTask.registerSchemas(MicroserviceRegisterTask.java:170) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.MicroserviceRegisterTask.doRegister(MicroserviceRegisterTask.java:122) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.AbstractRegisterTask.doRun(AbstractRegisterTask.java:41) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.AbstractTask.run(AbstractTask.java:53) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.CompositeTask.run(CompositeTask.java:35) [service-registry-1.3.2.jar!/:1.3.2]    at org.apache.servicecomb.serviceregistry.task.ServiceCenterTask.run(ServiceCenterTask.java:115) [service-registry-1.3.2.jar!/:1.3.2]    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_191]    at java.util.concurrent.FutureTask.runAndReset$$$capture(FutureTask.java:308) [?:1.8.0_191]    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java) [?:1.8.0_191]    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_191]    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_191]    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]    at org.apache.servicecomb.serviceregistry.registry.RemoteServiceRegistry$1.run(RemoteServiceRegistry.java:62) [service-registry-1.3.2.jar!/:1.3.2]Caused by: com.huawei.nuwa.map.http.HttpException: {"code":400,"error":"schemaId is not belong to the service"}    at com.huawei.nuwa.map.http.AsyncHttpClientImpl.restApi(AsyncHttpClientImpl.java:69) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.RestApiClient.signAndSendRequest(RestApiClient.java:119) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]    at com.huawei.nuwa.map.client.RestApiClient.restApi(RestApiClient.java:70) ~[nuwa-cloudmap-core-1.0.1.105.jar!/:?]

微服务是软件开发中的一种设计风格，以微服务的标准涉及软件。将一个单体（monolithic)的应该拆分成一个个的小组件，来进行开发。微服务的特点：服务组件化每个服务独立开发、部署,有效避免一个服务的修改引起整个系统重新部罢。技术栈灵活约定通信方式,使得服务本身功能实现对技术要求不再那么敏感。独立部署每个微服务独立部署,加快部署速度,方便扩展。扩展性强每个微服务可以部署多个,并且有负载均衡能力。独立数据每个微服务有独立的基本组件,例如数据库、缓存等。微服务的不足：沟通成本：每个组件独立部署，可能由不同项目组不同人员独立开发，需要更多的沟通成本。数据一致性：数据独立放置，多个副本之间的一致性运维成本：成倍增加基础通信、监控、管理组件，增加运维成本内部架构复杂性：组件之间的调用、依赖关系，增加了内部架构的复杂性。rpc\消息队列、数据库等等。更复杂的测试用例微服务解决了传统单体开发的软件面对的升级、弹性容量、高可用性面临的问题，也带来了一些新的挑战。

厉害啊我的天啊 483271 水电费

问题A：我的手机网站和PC网站打开完全不一样，不是一个站，是否是后台错误，打开了别人的？问题B：我是用一健生成把PC站转换成手机站后，样式有些错乱，这是什么问题？问题C：我分别对一个产品详情页制作了PC页面和手机页面，但是我用链接引用它们时，所指向的链接内容PC端和手机端不同步。如果在pc端修改好的链接内容，到了手机端就无法正确显示；如果在手机端修改好的链接内容，到了PC端就无法正确显示。问题D：我的手机版或者生成的APP页面在手机品牌A上显示正常，但是在品牌B上少字，错位，显示不正常了？ 下面逐一解答这三个问题：问题A：我的手机网站和PC网站打开完全不一样，不是一个站，是否是后台错误，打开了别人的？现象是打开同一个网址，但是用手机和用PC访问内容不一样，如下图： 原因：云速建站PC站和手机站是两个独立的站。访问时支持PC端和手机端访问自适应。PC访问会导向PC站，手机访问会默认导向手机站。如果用户只编辑了PC站，没编辑默认的手机站，打开就会不一样。解决方法是：A 完善手机站编辑。B 就想让PC和手机访问都访问PC站，可以强制设置手机访问PC站，操作方式是在域名绑定的时候只绑定PC问题B：我是用一健生成把PC站转换成手机站后，样式有些错乱，这是什么问题？现象是PC页面编辑显示的效果很好，但是生成手机页面很乱，如下图：   原因：云速建站PC站和手机站是两个独立的站。PC端的插件有部分在手机端不支持，生成后这部分插件就用别的插件替代了，替代不了的就会删除。因此手机站样式会变，需要再调整优化。目前支持转换的插件有：文章分类/文章列表/百度地图/容器/按钮/在线客服/线条/图片/导航/文本/会员登录（页脚中的模块不会被转换）解决方法：手动调整优化，部分设计使用手机版插件重新完成

云原生时代的微服务又有什么特点?当前有哪些比较活跃的微服务项目?阿里巴巴资深技术专家李响从微服务的生命周期、流量治理、编程模型以及可信安全4个方面，分享他对微服务与云原生之间的关系的理解。云原生时代，微服务和云原生会产生怎样的关系?云原生时代的微服务又有什么特点?当前有哪些比较活跃的微服务项目?阿里巴巴资深技术专家李响从微服务的生命周期、流量治理、编程模型以及可信安全4个方面，分享他对微服务与云原生之间的关系的理解。微服务架构与云原生微服务从 2010 年左右开始兴起。最开始大家会把微服务架构应用在传统 IT 的基础设施，也就是传统的 IDC 或者说物理机上，我们使用这些物理机为我们的微服务架构提供资源，形成一个分布式的系统，互相协作、协同。随着我们整个的 IT 基础设施的发展，逐步到了云的时代。我们在云时代做的第一步是云托管，也就是把在传统 IDC 之中的物理机，换成云上的虚拟机以及云上虚拟的弹性资源，对于微服务架构其实改动并不是非常巨大。我们把原来部署在物理机上的架构模型，可以比较容易地转到在云上托管的虚拟机中，也称之为 Lift and Shift 方式。与此同时，在云托管时代，我们也尝试更好利用云上虚拟机的弹性能力，去做一些微服务的自动化水平扩缩容。随着技术进一步发展，到云原生时代，到底什么不同了?云原生希望能够把像微服务、DevOps 这些架构和理念，能够和云所提供的服务、能力、平台更好地进行融合、进行协同和协作。我们希望云不光光是提供弹性物理资源，比如说存储、计算、网络等资源，而是能够为微服务提供更好的一个运行环境和平台。这个需要我们做到以下两点：对资源层面联合优化，对资源的更优使用。对云服务与平台的充分利用，研发、运维效率的极大提升。这个其实是云原生想去做的事情，就是让我们的微服务架构和体系，能够和云与云上面的服务、平台，以最佳的方式工作、协同在一起，降本提效。微服务与云原生如果我们以微服务为中心去看待微服务与云原生，可以从四个点讲一讲它们之间的关系，以及微服务在云原生时代的演进。生命周期的管理。流量治理。编程模型。可信安全。生命周期从本质上来讲，微服务就是把单体应用从一个巨型的应用拆分成数个更微小的服务，协作完成原来单体应用所提供的等效业务服务。因此，服务与服务之间会有依赖关系，服务也需要去部署到一个或多个资源上。原来的单体应用与资源之间的关系其实是一对一的关系，单体应用的协同也都是一些内部协同，不存在外部动态的依赖。而当我们转换到微服务之后，可以看到这张图会变成网状，变得复杂起来。因此由于内在原因，超过 50% 的企业会认为微服务架构或采用微服务架构，其中最大的挑战在于更为复杂的运维，也就是更为复杂的生命周期管理。

作者名：关耳山石作者博客链接：https://bbs.huaweicloud.com/community/usersnew/id_1593343710234702 摘要：对于一个合格的CloudNative应用，应该把自己的程序当做开源软件来编写的，不该将数据库连接信息和密码放在代码里，一定要将配置外置。对于一个合格的CloudNative应用，应该把自己的程序当做开源软件来编写的，不该将数据库连接信息和密码放在代码里，一定要将配置外置。因此我试着在华为云上落地这套标准，期间尝试了从ServiceStage、CCE、CSE这三个入口进行配置注入，最终实现能够在应用启动时，主动拉取配置，覆盖本地配置文件里的调试配置，并能够在线配置并生效。打法是：CCE配置启动参数，制定SpringProfiles；配合CSE做应用配置，将资源外置后的配置记录于此，并可以动态更新，最终实现了配置外置的诉求。另外，通过这次增加的多版本管理，尝试梳理了一下ServiceStage的组件、CCE的workload、CSE的应用和微服务之间，错综复杂的概念之间的关系，个人浅见，欢迎指正：1. 初始化配置在系统初始化的时候，不可能一点配置都没有，所以保留一些基础配置在配置文件里是有必要的。配置外置并不意味着100%的配置都要外置，而是把外部依赖资源的配置，特别是容易变化配置外置。1.1 启用Bootstrap和Spring profile在代码层面，首先要进行基础配置。先看代码结构，这里除了最基本的application.yaml，增加了bootstrap.yaml和*-dev.yml等带后缀的文件。介绍一下原理：首先介绍Bootstrap Application Context：它是Spring Cloud Context的父Context，所以从外部配置源里加载配置一般从这里来，且优先级高于其他一切配置文件。于是，我们也利用这个能力，借助CSE的微服务配置中心能力，进行Spring的外部参数写入。然后介绍Spring profiles：为了把通用配置和环境相关的配置区分开，比如DEV环境没有AK/SK认证，而线上环境都有认证，这种配置项上的区别，引入了Spring profiles的概念，当Springboot启动的时候，会根据profiles.active参数判断应该启用那个环境配置PS：参考SpringCloud官方解释另外，就是哪些配置应该放在配置文件里，理论上除了最基础的配置，在启动时使用的，其余的配置都可以放在CSE的微服务配置中心里，而不必在本地配置文件里存在，另外就是本地配置里存在的，也可以通过二次设置在微服务的配置中心里，进行覆盖，比如数据库连接池的大小，而不需要修改代码，至于改完以后，要不要重启，那就得看生效的逻辑了。1.2 引入CSE配置中心CSE配置中心引入，需要先引入依赖包，然后在bootstrap.yaml中配置CSE配置中心的地址、认证信息等。这里可以参考官方文档，主要关注bootstrap.yaml的配置参数：使用分布式配置中心补充：获取spring-cloud-starter-huawei-config的版本参考地址：huaweicloud/spring-cloud-huawei可以参考现有的SpringCloud基线版本，选择SpringCloud-Huawei的版本补充：关于配置中心的优先级微服务引擎提供了分层次的配置机制。按照优先级从高到低，分为：配置中心（动态配置）Java System Property（-D参数）环境变量配置文件参考官方文档：配置微服务2. 本地CSE配置中心能力验证前提条件，本地得安装一个Local-CSE并启动，这部分参考云上DevOps：2.1-本地环境准备2.1 配置application.yaml和bootstrap.yml原始文件可以参考Github的Demo，配置文件入口，我这里进行了修改，因为bootstrap.yaml优先级高于application.yaml，参数只要在bootstrap.yaml中出现过，就不会使用application.yaml中的配置了。上代码，application.yaml，可以看到配置很少，因为大部分bootstrap.yml中已经包含，就都去掉了这是bootstrap.yml，注意这里的spring.application.name、spring.cloud.servicecomb.discovery.appName和spring.cloud.servicecomb.discovery.version会组成一个微服务私有的参数作用域，这里的优先级高于全局作用域application。特别注意，云上的CSE环境，除了上面提到的，还需要增加server.env参数。另外，server.env有四个参数可以选development、testing、acceptance、production关于如上参数的定义，参考官方文档：使用分布式注册中心和官方文档：使用分布式配置中心。2.2 准备验证代码直接上代码2.3 静态配置能力为了验证CSE配置中心的参数，是否能覆盖application.yaml中的参数配置，我选了一个很特别的参数：spring.datasource.password，如果能够覆盖成功，那么启动后，创建数据库连接池一定会报错。首先，打开本地CSE配置中心，地址为：http://localhost:30106/#/cse/services/config，创建一个配置项，作用域选VodMgrService@CabgOne#1.0.0，关于application的作用域后面再解释。重启本地微服务，启动后创建数据库连接池就报错了，符合预期。结论：CSE配置中心的参数，能够覆盖application.yaml中的参数配置2.4 动态配置能力为了验证CSE配置中心的参数动态生效，需要使用注解@RefreshScope，同时也引入ConfigRefreshEvent来监听事件变化，这样就会得到一个效果，对于动态生效的参数，可能需要一些重建或刷新，比如连接池、缓存、Client等。首先，增加一个配置项config.value然后很快可以看到后台日志打印出来，包括自己的监听器，也响应了日志查看一下数据，已经响应为TryMe具体的配置，在后台是轮询的，响应周期配置参数为cloud.servicecomb.config.watch.delay，目前是10秒一次修改一下配置，为TryMeAgain

如下图所表示的，修改了yaml文件，然后报错了。已经替换了几次ak/sk，而且都是新建的ak/sk，还是超出了次数。怎么解决呢？？？？？在线等。