知识卡反馈有礼，点这里！知识卡原文链接：DevOps组织如何有效地实施MSA往期卡片回顾：【敏捷智库知识卡】第1-7期合集【敏捷智库知识卡】 第8期 拍脑袋估算法？OUT!：科学估算，平稳生产，嗷闪！高清无水印知识卡请点击附件下载

2020年之初，新冠疫情突发而至，员工需要居家隔离远程办公，部分企业乱了阵脚，难以运转。但有超过19.4万名员工的华为却很稳：工作照常进行，业务照常运营，几乎没有受到太多影响。如此抗风险能力，不得不服。这背后，华为推进多年的数字化转型功不可没，成为其疫情之下高效运转的强力支撑点。但它带来的益处并不仅仅体现在特殊时期，在华为的日常运营中，也切切实实发挥出了降本增效的作用。比如在华为的全球供应链，数字化转型之后，可以自动化实现80%的确定性作业，推动整体物流效率提升了40%；而且50%的供应决策，都可以通过数字化系统自动实现。这能够带来怎样的经济效益，可想而知。而这样的情况，正出现在华为遍布全球900多个分支机构，15个研发中心，36个创新基地中，以及170多个国家和地区的业务中。华为这个成立超过30年的超大型组织，正在乘风破浪，方方面面都在经历一次深刻的数字变革，期待迎来一场新的蜕变。它是怎么做到的？华为云BU副总裁、华为云首席数字化转型官苏立清，1996年加入华为，2012年接管了华为IT工程部门，是华为这一历史进程的见证者，更是参与者，且听他细细道来。今天，我们就把聚光灯对准华为本身，看看作为最佳试验场的华为是怎么做数字化转型的？有哪些成功的故事，又有哪些磕碰起伏？哪些值得其他企业可借鉴的方法论？△华为云BU副总裁、首席数字化转型官苏立清（右）与钛媒体联合创始人/首席研究官、ITValue发起理事万宁（左）在Cloud & AI Live分享数字化转型实践战略上高度重视：数字化转型是2023年前公司唯一变革重点对华为数字化转型最为清晰且直接的认知要回溯到2018年10月的全联接大会。在这场华为的年度盛会上，华为对外明确表明了对数字化转型的态度：从2018年起，华为就决定把数字化转型作为公司未来5年唯一的变革重点。希望通过打造Digital First，即实现全联接的智能华为，成为行业标杆。转型的动机和众多想要推进数字化转型的企业一脉相承：对外让华为与用户和客户做生意，简单、高效、安全；对内逐步提升运营的效率和效益。现在已经行至半途，一个新的华为开始浮出水面，华为多年数字化转型工程交出了初步的成绩单。现在的华为员工，只用一个智能办公平台华为云WeLink，就可以完成各种业务活动，而不是再像此前那样，想要完成一个作业，登录一个又一个烟囱系统。整个过程看似很简单，但在操作起来却是一个“牵一发而动全局性”的动作。在华为看来，企业的数字化转型要转的绝对不是一个方面，从意识、组织、文化，到方法和模式都要转，任何一个方面都不能落下，否则就会影响整体进程。可每一部分具体要怎么转？苏立清也分别给出了华为的方法论和实践案例。五个维度上的转变：华为数字化“铁三角”架构首先是转意识，数字化转型绝不只是IT部门的任务，随着业务的数字化程度越来越高，需要IT系统要更加快速地、更加敏捷地反映业务的本质。所以就要求数字化转型一定要跟业务贴近起来，用AI、大数据、云计算、区块链、5G等信息技术，来帮助业务提升效率。业务方面也是如此，需要回归到价值发掘上，以客户为中心来帮助业务创造价值，只有技术和业务进行深度的融合，深度的协同，才能产生数字化转型的一个成功落地的价值。其次是转组织。过去的组织模式，往往是业务部门提需求给IT部门，IT做出一个IT系统来满足业务的诉求。苏立清说，这有点像“老母鸡下蛋，提一个需求，IT做一个响应。”而在业务快速迭代的情况下，需要信息架构敏捷、快速地响应诉求，这种旧的组织模式难以满足，需有在技术和业务协同，变成“火腿肠架构，你中有我，我中有你”。在华为内部，数字化转型有个铁三角格局：一是BET团队（Business Enable Team），是IT和业务深度融合的混编团队，服务华为所有国家区域在内的各个业务部门，跟业务一起协同满足业务的诉求。二是使能IT系统的华为IT服务（HIS），利用统一的云化服务化平台，来管理整个IT服务，用技术创新来驱动业务的成长。三是运营指挥中心（OCC），实现监测、预警、联动、指挥等行为，以实现业务监控、业务预测、业务预警、业务协调、业务调度、业务决策和业务指挥。在此之外，华为也在6年前成了一个公司级数据治理架构的工作组，从元数据治理开始，来进行数据治理工作。这在很多大型公司中，都是非常难推进的环节，不仅要打破部门与部门之间的隔阂，还要对数据有很强的认知能力。但这也是必须要做的事情，只有底层的数据是干净和可用的，各种新型的技术，比如人工智能的种种算法，才能发挥其中的价值。转文化方面，微服务化已经成为一个趋势，来更好的解构业务。苏立清说，过去的状况，大多是一个需求产生了一类软件包来帮助业务实现模式，在未来可能不够。这就需要新的平台型架构，来适应业务快速响应的时代。每一个使用平台的人，也都是平台的建构者，形成一个不断迭代的新型架构，来满足企业更高的一个数字化转型的需要。苏立清透露，华为已经在200多个场景中实现了微服务化。转方法则涉及到在业务中如何具体操作，才能够更好地推进数字化转型进程。在今天的华为Cloud & AI Live节目中，苏立清一共提到了3个方面：一是业务对象数字化，尽可能地把业务对象以及各个场景的业务对象解构出来，实现数字化。二是业务流程线上化，改变过去软件包帮助固化业务流程的情况，把业务本质的一些东西尽可能从线下转到线上，让IT可以发挥作用。三是业务规则结构化，把沉淀在业务人员脑中的大量规则进行结构化，然后把结构化进行数字化，并交由IT系统处理，来提高效率。以上三方面综合起来，就能实现业务自动化，真正为业务的高效运转产生一个很大的价值。比如华为对数字交易环节的改造。此前华为发展和认证合作伙伴，或者对合作伙伴进行管理的时候，需要基于一系列管理文件去适配，这中间往往需要员工大量的手工操作。现在华为对整个业务流程进行了数字化改造，把管理文件中的规则进行解构之后，通过系统自动完成，从而大大提升了效率。苏立清说，目前华为中国区的合作伙伴认证管理中，63%的业务都已经是系统自动完成了，涉及到交易环节，也有33%可以系统自动完成。转模式则是关乎于企业本身存在的大量存量IT系统。这些系统的架构往往都存在一定的老旧化状态，在这样的状况下，构建新型架构应该怎么办？在苏立清看来，这是一个两难的选择：如果保护过去的投资，未来可能就会落后。如果把存量系统全部干掉，其实每个企业也很难做到。怎么办？全都要！华为提出了一种Bi-Model双模方式，既对过去的存量系统进行使用，通过数据把它们联接起来，而且在新建的系统中，以云为基础，打造数据驱动的微服务化新型架构。苏立清说，这样既能拥抱未来，也能适应过去，不至于浪费此前的投入。但这并不意味着是对老旧系统的妥协，在这种模式下能够保证业务正常运转，但同时也需要去寻找创新点，对系统进行适度的优化，提升整体能力。华为的做法是前、中、后台分层解耦，实现云化、服务化。做稳后台，是以“软件包”为基础，构建业务交易和应用骨干，如原来的ERP都是小型机架构，在2017年春节时，将其迁移到X86架构上，推动其性能提升了10倍。做强中台，是基于“业务对象、业务过程、业务规则”构建应用服务， 开放API市场，然后在新型架构上可以用微服务来构建面向未来业务场景的应用，来实现灵活响应，面向新业务的快速高效的运作。做轻前台，以员工为例，华为打造出了WeLink—更好地联接人、联接业务、联接设备、联接知识。然后通过卡片服务，中台和后台形成联接，这样的话，就满足了以用户为中心，一站式的作业，用户体验就得到了大幅提升。这些坚实的数字化转型基础设施，造就了当前的华为业务运作模式，实现了降本增效。苏立清分享了华为数字化改造本身的案例：在数字化改造之前，整个供应支出占华为销售收入的4.3%。到数字化完成以后降低到3%，每年节省了一个多的百分点，就是十几亿美金。他说，这证明了：通过数字化来提升业务效率，可以直接节省投资。放到整个华为来看，整个组织作战能力也得到了大大加强——有些区域已经实现100%在线进行管理业务活动。在这次疫情中，华为能够实现持续的运转，没受到太多影响，其数字化转型，确实发挥了非常大的作用。转型的关键是什么？相对于一些企业的数字化，不过是业务和数字化“两张皮”的状况，华为数字化转型为什么已带来这么多实质性的提升？在苏立清看来，核心在于怎么调好业务和技术的“双人舞”。华为数字化转型的“十六字”秘诀苏立清在1996年加入华为之后，在接管华为IT工程部门之前，先后历任北京研究所STP产品经理、数通产品线总监、北京研究所所长、存储与网络安全产品线总裁等职位，在业务上有着丰富经验。苏立清感慨，早期的IT部门，技术能力以及对业务部门的响应其实是有Gap的，并没有很好地满足业务部门需求。这个时候业务部门给IT的压力比较大，批判的声音比较多，当时华为内部的心声社区上有很多对IT批评的声音。他说，华为之所以能够将数字化转型顺利推进下来，除了各方的努力，还在于平衡好了业务和技术的关系：在数字化的过程中，想有所效率，需要是双人舞，IT的舞步要踩到业务的步调上，而不要踩到业务的脚上。这也是华为数字化转型方法论的一部分。在复盘华为数字化转型这些年的过程，苏立清提炼出了十六字箴言：上下同欲、双轮驱动、眼高手低、立而不破。上下同欲在于，数字化转型需要企业高层重视，来驱动企业形成一个数字化转型文化，才能构建出数字化转型的基础。双轮驱动也就是“双人舞”，需要业务和IT一起来共同参与来做数字化转型，毕竟数字化转型本质上是信息技术来帮助业务提升效率。眼高手低是对准价值，数字化转型一定是要有一个总体规划，要特别关注落地的效果，一定是要产生价值，从而催生数字化转型氛围，不断地迭代形成一个马太效应。立而不破，则是在数字化转型中，拥抱面向未来的，基于云、大数据和人工智能等新技术，以数据为驱动的新型IT架构同时，也要将过去存量的系统融合进来，这样企业才能连续运转。虽然字很少，方法论很精炼，但数字化转型之路，也充满坎坷。在苏立清看来，数字化转型没有终点，要持续地、不断地演进。而华为自身，还要在数字化转型的道路上不断地深化和前行。最后，他分享了激励自己的“荔枝树”故事：荔枝树其实承受了很大的创伤（做环割）之后，才能产生一个动力，结出果实。这与当年他刚刚接管IT工程部门时，遭遇大量业务部门批评的情景产生了契合，也成了他带队做好业务系统的力量来源之一：企业的数字化转型中也是同样的道理，只有将压力转化为动力，才能有价值出现。@量子位 · 追踪AI技术和产品新动态

【转载华为云社区】大家言必称云原生，却鲜少有人告诉你到底什么是云原生，若是找资料来看，读完大多会感觉云绕雾罩，一知半解，总之虚得很；甚至会让你一度怀疑自己的智商，不过我对于读不懂的文章，一律归因于写文章的人太蠢，当然这不一定是事实，但这样的思考方式能让我避免陷入自我怀疑的负面情绪。云原生之所以解释不清楚，是因为云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。何谓云原生？技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命**、评优晋级不可多得的终极绝密武器。云元素的四要素微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。如何云原生？首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。1. 本地部署的传统应用往往采用c/c++、企业级java编写，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写。2. 本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。3. 本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。4. 本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。5. 本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。6. 本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。7. 本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。技术的趋势和影响软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。如果说PC时代的基础设施是控件库，互联网时代的基础实施是云，那AI时代基础设施是什么？又会有什么高端玩法？---------------------------作者：“人民副首席码仔”

2020年之初，新冠疫情突发而至，员工需要居家隔离远程办公，部分企业乱了阵脚，难以运转。但有超过19.4万名员工的华为却很稳：工作照常进行，业务照常运营，几乎没有受到太多影响。这背后，华为推进多年的数字化转型功不可没，成为其疫情之下高效运转的强力支撑点。但它带来的益处并不仅仅体现在特殊时期，在华为的日常运营中，也切切实实发挥出了降本增效的作用。比如在华为的全球供应链，数字化转型之后，可以自动化实现80%的确定性作业，推动整体物流效率提升了40%；而且50%的供应决策，都可以通过数字化系统自动实现。这能够带来怎样的经济效益，可想而知。而这样的情况，正出现在华为遍布全球900多个分支机构，15个研发中心，36个创新基地中，以及170多个国家和地区的业务中。华为这个成立超过30年的超大型组织，正在乘风破浪，方方面面都在经历一次深刻的数字变革。它是怎么做到的？华为云BU副总裁、华为云首席数字化转型官苏立清，1996年加入华为，2012年接管了华为IT工程部门，是华为这一历史进程的见证者，更是参与者，且听他细细道来。作为最佳试验场的华为，是怎么做数字化转型的？有哪些成功的故事，又有哪些磕碰起伏？哪些值得其他企业可借鉴的方法论？▲ 华为云BU副总裁、首席数字化转型官苏立清（右）钛媒体联合创始人、ITValue发起理事万宁（左）6月22日在Cloud & AI Live分享数字化转型实践战略上高度重视：数字化转型是2023年前公司唯一变革重点对华为数字化转型最为清晰且直接的认知要回溯到2018年10月的全联接大会。在这场年度盛会上，华为对外明确表明了对数字化转型的态度：从2018年起，华为就决定把数字化转型作为公司未来5年唯一的变革重点。希望通过打造Digital First，即实现全联接的智能华为，成为行业标杆。华为与用户和客户做生意，简单、高效、安全；对内逐步提升运营的效率和效益。现在已经行至半途，华为多年数字化转型工程交出了初步的成绩单。现在的华为员工，只用一个智能办公平台华为云WeLink，就可以完成各种业务活动，而不是再像此前那样，想要完成一个作业，登录一个又一个烟囱系统。整个过程看似很简单，但在操作起来却是一个“牵一发而动全局性”的动作。在华为看来，企业的数字化转型要转的绝对不是一个方面，从意识、组织、文化，到方法和模式都要转，任何一个方面都不能落下，否则就会影响整体进程。可每一部分具体要怎么转？苏立清也分别给出了华为的方法论和实践案例。五个维度上的转变：华为数字化“铁三角”架构首先是转意识，数字化转型绝不只是IT部门的任务，随着业务的数字化程度越来越高，需要IT系统要更加快速地、更加敏捷地反映业务的本质。所以就要求数字化转型一定要跟业务贴近起来，用AI、大数据、云计算、区块链、5G等信息技术，来帮助业务提升效率。业务方面也是如此，需要回归到价值发掘上，以客户为中心来帮助业务创造价值，只有技术和业务进行深度的融合，深度的协同，才能产生数字化转型的一个成功落地的价值。其次是转组织。过去的组织模式，往往是业务部门提需求给IT部门，IT做出一个IT系统来满足业务的诉求。苏立清说，这有点像“老母鸡下蛋，提一个需求，IT做一个响应。”而在业务快速迭代的情况下，需要信息架构敏捷、快速地响应诉求，这种旧的组织模式难以满足，需有在技术和业务协同，变成“火腿肠架构，你中有我，我中有你”。在华为内部，数字化转型有个铁三角格局：一是BET团队（Business Enable Team），是IT和业务深度融合的混编团队，服务华为所有国家区域在内的各个业务部门，跟业务一起协同满足业务的诉求。二是使能IT系统的华为IT服务（HIS），利用统一的云化服务化平台，来管理整个IT服务，用技术创新来驱动业务的成长。三是运营指挥中心（OCC），实现监测、预警、联动、指挥等行为，以实现业务监控、业务预测、业务预警、业务协调、业务调度、业务决策和业务指挥。在此之外，华为也在6年前成了一个公司级数据治理架构的工作组，从元数据治理开始，来进行数据治理工作。这在很多大型公司中，都是非常难推进的环节，不仅要打破部门与部门之间的隔阂，还要对数据有很强的认知能力。但这也是必须要做的事情，只有底层的数据是干净和可用的，各种新型的技术，比如人工智能的种种算法，才能发挥其中的价值。转文化方面，微服务化已经成为一个趋势，来更好的解构业务。苏立清说，过去的状况，大多是一个需求产生了一类软件包来帮助业务实现模式，在未来可能不够。这就需要新的平台型架构，来适应业务快速响应的时代。每一个使用平台的人，也都是平台的建构者，形成一个不断迭代的新型架构，来满足企业更高的一个数字化转型的需要。苏立清透露，华为已经在200多个场景中实现了微服务化。转方法则涉及到在业务中如何具体操作，才能够更好地推进数字化转型进程。在今天的华为Cloud & AI Live节目中，苏立清一共提到了3个方面：一是业务对象数字化，尽可能地把业务对象以及各个场景的业务对象解构出来，实现数字化。二是业务流程线上化，改变过去软件包帮助固化业务流程的情况，把业务本质的一些东西尽可能从线下转到线上，让IT可以发挥作用。三是业务规则结构化，把沉淀在业务人员脑中的大量规则进行结构化，然后把结构化进行数字化，并交由IT系统处理，来提高效率。以上三方面综合起来，就能实现业务自动化，真正为业务的高效运转产生一个很大的价值。比如华为对数字交易环节的改造。此前华为发展和认证合作伙伴，或者对合作伙伴进行管理的时候，需要基于一系列管理文件去适配，这中间往往需要员工大量的手工操作。现在华为对整个业务流程进行了数字化改造，把管理文件中的规则进行解构之后，通过系统自动完成，从而大大提升了效率。苏立清说，目前华为中国区的合作伙伴认证管理中，63%的业务都已经是系统自动完成了，涉及到交易环节，也有33%可以系统自动完成。转模式则是关乎于企业本身存在的大量存量IT系统。这些系统的架构往往都存在一定的老旧化状态，在这样的状况下，构建新型架构应该怎么办？在苏立清看来，这是一个两难的选择：如果保护过去的投资，未来可能就会落后。如果把存量系统全部干掉，其实每个企业也很难做到。怎么办？全都要！华为提出了一种Bi-Model双模方式，既对过去的存量系统进行使用，通过数据把它们联接起来，而且在新建的系统中，以云为基础，打造数据驱动的微服务化新型架构。苏立清说，这样既能拥抱未来，也能适应过去，不至于浪费此前的投入。但这并不意味着是对老旧系统的妥协，在这种模式下能够保证业务正常运转，但同时也需要去寻找创新点，对系统进行适度的优化，提升整体能力。华为的做法是前、中、后台分层解耦，实现云化、服务化。做稳后台，是以“软件包”为基础，构建业务交易和应用骨干，如原来的ERP都是小型机架构，在2017年春节时，将其迁移到X86架构上，推动其性能提升了10倍。做强**，是基于“业务对象、业务过程、业务规则”构建应用服务， 开放API市场，然后在新型架构上可以用微服务来构建面向未来业务场景的应用，来实现灵活响应，面向新业务的快速高效的运作。做轻前台，以员工为例，华为打造出了WeLink——更好地联接人、联接业务、联接设备、联接知识。然后通过卡片服务，**和后台形成联接，这样的话，就满足了以用户为中心，一站式的作业，用户体验就得到了大幅提升。这些坚实的数字化转型基础设施，造就了当前的华为业务运作模式，实现了降本增效。苏立清分享了华为数字化改造本身的案例：在数字化改造之前，整个供应支出占华为销售收入的4.3%。到数字化完成以后降低到3%，每年节省了一个多的百分点，就是十几亿美金。他说，这证明了：通过数字化来提升业务效率，可以直接节省投资。放到整个华为来看，整个组织作战能力也得到了大大加强——有些区域已经实现100%在线进行管理业务活动。在这次疫情中，华为能够实现持续的运转，没受到太多影响，其数字化转型，确实发挥了非常大的作用。转型的关键是什么？相对于一些企业的数字化，不过是业务和数字化“两张皮”的状况，华为数字化转型为什么已带来这么多实质性的提升？在苏立清看来，核心在于怎么跳好业务和技术的“双人舞”。华为数字化转型的“十二字”秘诀苏立清在1996年加入华为之后，在接管华为IT工程部门之前，先后历任北京研究所STP产品经理、数通产品线总监、北京研究所所长、存储与网络安全产品线总裁等职位，在业务上有着丰富经验。苏立清感慨，早期的IT部门，技术能力以及对业务部门的响应其实是有Gap的，并没有很好地满足业务部门需求。这个时候业务部门给IT的压力比较大，批判的声音比较多，当时华为内部的心声社区上有很多对IT批评的声音。他说，华为之所以能够将数字化转型顺利推进下来，除了各方的努力，还在于平衡好了业务和技术的关系：在数字化的过程中，想有所效率，需要是双人舞，IT的舞步要踩到业务的步调上，而不要踩到业务的脚上。这也是华为数字化转型方法论的一部分。在复盘华为数字化转型这些年的过程，苏立清提炼出了十二字箴言：上下同欲、双轮驱动、眼高手低、立而不破。上下同欲在于，数字化转型需要企业高层重视，来驱动企业形成一个数字化转型文化，才能构建出数字化转型的基础。双轮驱动也就是“双人舞”，需要业务和IT一起来共同参与来做数字化转型，毕竟数字化转型本质上是信息技术来帮助业务提升效率。眼高手低是对准价值，数字化转型一定是要有一个总体规划，要特别关注落地的效果，一定是要产生价值，从而催生数字化转型氛围，不断地迭代形成一个马太效应。立而不破，则是在数字化转型中，拥抱面向未来的，基于云、大数据和人工智能等新技术，以数据为驱动的新型IT架构同时，也要将过去存量的系统融合进来，这样企业才能连续运转。虽然字很少，方法论很精炼，但数字化转型之路，也充满坎坷。在苏立清看来，数字化转型没有终点，要持续地、不断地演进。而华为自身，还要在数字化转型的道路上不断地深化和前行。最后，他分享了激励自己的“荔枝树”故事：荔枝树其实承受了很大的创伤（做环割）之后，才能产生一个动力，结出累累果实。这与当年他刚刚接管IT工程部门时，遭遇大量业务部门批评的情景产生了契合，也成了他带队做好业务系统的力量来源之一：企业的数字化转型中也是同样的道理，只有将压力转化为动力，才能有价值出现。

一直觉得做的太顺利的实验没什么意思，这不，年度重头戏来了，有挑战性，折磨人，然后还有趣！--weathermap微服务搭建目前为止，还没做过去，大侠先留步，就凭俺着死缠烂打的功夫，肯定能做过去的啦~只要实验不撤！233333333~第一关：rds数据库的购买这里有几个小坑，要严格按照手册购买数据库，错一点也不行，这个涉及到钱的，你要求了超额的数据库配置，就会跟我一样被强行清退资源，浪费时间。然后新建数据库，很简单的，就把sql粘过来就行了，然后，你会发现，看不见数据库.这里也好理解，看不见但却存在，页面显示的问题呗，那么怎么破？好办，换个界面，直接去库管理界面，不行就退出再重进一遍，数据库就出来了，但首页面还是没有，这里估计有bug.买好了数据库，建好了表，就ok了。还需要注意的地方是，数据库的搭建大致需要3-6分钟，一定要等它完事再登录。这段时间预习下面的手册。第二关：购买集群这里也比较耗时，原因在于，最小的粒度是50个节点起步，多做几遍就熟悉了，没啥说的，就是熟能生巧。几次失败都是没有完全按照手册操作。第三关：微服务的构建目前正卡在这里，领导找问话，不得以中止了。一看时间，不够了。昨天我发了个帖子建议隔天实验清空重新开始，看来少考虑了这个引用环境：有事挂起的场景。好在华为云的管家不听我的，哈哈哈哈，明天继续。。。。。

实验实际的时间是3个小时，这里有点小出入。另外，能否建议实验退出按钮即彻底清算资源，包括实验的时长。因为如果发生了致命的错误而中止实验，希望是第二天新环境重新做实验，而不是把剩余的时间耗尽。这个退出的设定，可能是考虑了由于网络原因或者是用户的临时终止实验而设置，那么，完全可以用日期来判断，如果是隔了天再登入，那么就彻底清退资源重新来过。

【华为云技术开放日3期直播免费报名】“见微知著，构见未来”，华为云技术开放日（第一季）3期直播免费报名通道已开启！报名戳：https://devcloud.huaweicloud.com/expert/open-assessment/qtn?id=cc8ff3b826fe4a43b628d0da521cc50a&utm_source=kfz_cdjd&utm_medium=zhibo&utm_campaign=202006192020年，充满了变化与不确定性挑战，VUCA时代，为了响应业务的快速变化，微服务架构成为很多企业的必然选择。6月19日、23日、30日晚8点，我们分别邀请到孙玄、陈丰、史海峰3位业内大咖，围绕“微服务架构与技术领导力”展开分享（详情见海报），带你掌握微服务架构设计与开发能力，提升技术领导力和职场竞争力。扫描图片二维码即可报名参加，直播间还设置了多轮现场抽奖，丰富礼品等你来拿~

导语：近期，国外HashiCorp在官网宣布，不允许中国境内使用、部署和安装该企业旗下的企业版产品和软件，其中包括Consul。那么国内企业有没有类似的服务可以提供呢？答案是有！我们一起来看看华为云ServiceStage。近年来越来越多的企业开始实践微服务，而微服务在企业应用落地的过程，面临着微服务开发框架的选型，无论是自研还是选择第三方框架都不得不考虑的问题包括：微服务框架是否具备高可靠性，任何时间不能中断业务；微服务框架是否能够实现高速通信性能，保证业务从单体架构向微服务架构切换时，性能下降不会太多。本文从服务管理中心、通信处理两个模块来介绍华为开源微服务框架 SeviceComb 如何帮助企业应用快速具备高性能的通信能力以及高可靠的服务管理能力。上篇先介绍微服务的服务管理中心。ServiceCenter 整体介绍图 1 ServiceCenter 整体介绍ServiceCenter 是一个具有微服务实例注册 / 发现能力的微服务组件，提供一套标准的 RESTful API 对微服务元数据进行管理。ServiceComb 的微服务注册及动态发现能力也是依赖其实现的。除了以上描述的微服务动态发现外，ServiceCenter 帮助应用具备以下能力：实例缓存机制基于 SDK 开发的微服务，会在第一次消费 Provider 微服务时，会进行一次实例发现操作，此时内部会请求 ServiceCenter 拉取 Provider 当前存活的实例集合，并保存到内存缓存当中，后续消费请求就依据该缓存实例集合，按照自定义的路由逻辑发送到 Provider 的一个实例服务中。这样处理的好处是，已经运行态的 SDK 进程，始终保留一份实例缓存；虽然暂时无法感知实例变化及时刷新缓存，但当重新连上 ServiceCenter 后会触发一缓存刷新，保证实例缓存是最终有效的；在此过程中 SDK 保证了业务始终可用。图 4 微服务实例缓存机制异步缓存机制在 ServiceCenter 内部，因为本身不存储数据，如果设计上单纯的仅作为一个 Proxy 服务转发外部请求到 etcd，这样的设计可以说是不可靠的，原因是因为一旦后端服务出现故障或网络访问故障，必将导致 ServiceCenter 服务不可用，从而引起客户端实例信息无法正确拉取和刷新的问题。所以在设计之初，ServiceCenter 引入了缓存机制。图 6 异步缓存机制1.    启动之初，ServiceCenter 会与 etcd 建立长连接（watch），并实时监听资源的变化。2.    每次 watch 前，为防止建立连接时间窗内发生资源变化，ServiceCenter 无法监听到这些事件，会进行一次全量 list 查询资源操作。3.    运行过程中，List & watch 所得到的资源变化会与本地缓存比对，并刷新本地缓存。4.    微服务的实例发现或静态数据查询均使用本地缓存优先的机制。异步刷新缓存机制，可以让 ServiceCenter 与 etcd 的缓存同步是异步的，微服务与 ServiceCenter 间的读请求，基本上是不会因为 etcd 不可用而阻塞的；虽然在资源刷新到 ServiceCenter watch 到事件这段时间内，会存在一定的对外呈现资源数据更新延时，但这是可容忍范围内的，且最终呈现数据一致；这样的设计即大大提升了 ServiceCenter 的吞吐量，同时保证了自身高可用。自我保护机制前面提到的缓存机制，保证了 ServiceCenter 在 etcd 出现网络分区故障时依然保持可读状态，ServiceCenter 的自我保护 (Self-preservation) 机制保证了 Provider 端与 ServiceCenter 在出现网络分区故障时依然保持业务可用。现在可以假设这样的场景：全网大部分的 Provider 与 ServiceCenter 之间网络由于某种原因出现分区，Provider 心跳无法成功上报心跳。这样的情况下，在 ServiceCenter 中会出现大量的 Provider 实例信息老化下线消息，ServiceCenter 将 Provider 实例下线事件推送到全网大部分的 Consumer 端，最终导致一个结果，用户业务瘫痪。可想而知对于 ServiceCenter 乃至于整个微服务框架是灾难性的。为了解决这一问题，ServiceCenter 需要有一个自我保护机制（Self-preservation）：图 8 ServiceCenter 的自我保护机制1.    ServiceCenter 在一个时间窗内监听到 etcd 有 80% 的实例下线事件，会立即启动自我保护机制。2.    保护期间内，所有下线事件均保存在待通知队列中。3.    保护期间内，ServiceCenter 收到队列中实例上报注册信息则将其从队列中移除，否则当实例租期到期，则推送实例下线通知事件到 consumer 服务。4.    队列为空，则关闭自我保护机制。有了自我保护机制后，即使 etcd 存储的数据全部丢失，这种极端场景下，SDK 与 ServiceCenter 之间可在不影响业务的前提下，做到数据自动恢复。虽然这个恢复是有损的，但在这种灾难场景下还能保持业务基本可用。以上就是 ServiceComb 的服务管理中心在分布式系统下的高可靠架构设计，在进行大规模、高并发的企业应用开发时，可靠的服务管理中心能够使得分布式系统运行更加稳定，同时高性能的通信也使得分布式系统更高效地处理密集的业务。TIPS:当前ServiceStage还有20个应用实例免费的活动，是real划算了，小伙伴们赶紧去体验。

         转载自：https://bbs.huaweicloud.com/blogs/170483        博文作者：无微不至            “未来的软件一定是生长于云上的”1. 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。下面是几条与云原生应用强相关的预测内容：分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的、无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。2. 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。2.1. 使用微服务的场景构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。2.2. 微服务应用在技术栈中的位置假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置： 红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。3. 实践 - 一元体验all above最后打个小广告：华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。开发者可以在云上享受开箱即用的微服务中间件，通过CSE微服务平台既可以学习实践又能作为生产实践，学习微服务可以跟进当下最新技术潮流。华为云回馈活动指路↓一元体验原价500元包周期引擎（100实例），快来体验吧！https://activity.huaweicloud.com/paas_devcloud0.html铛铛铛~新用户体验，还有码豆回馈，豪礼多多喔！CSE还提供了免费试用产品（20实例）回馈广大开发者，快来试用吧https://console.huaweicloud.com/servicestage/?region=cn-east-2&package=basic&new=true#/appdev/engine/list 

DevOps，是Development和Operations的组合词，是指一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。DevOps的出现，源于在传统模式下的开发和运维组织上的分离造成的管理混乱，开发要不断的迭代新版本上线新功能，但是运维关注的是稳定，这两种需求实际上是矛盾的。但DevOps旨在打破这道混乱之墙，让开发、运维、测试协同作战，提高研发效率，实现高效交付，解决传统模式下的运维之痛。而事实证明，DevOps确实能够较好的解决开发和运维之间的混乱问题，提升研发效率，实现高效交付。在近期中国信通院（CAICT）发布的《中国DevOps现状调查报告（2019年）》（以下简称报告）中，超八成企业表示，通过采用DevOps中的核心工程实践——持续交付——获得了研发效率的显著提升。同时调查发现，具备清晰、明确变更管理系统的组织，平均变更前置时间（即从代码被成功提交到成功运行在生产环境平均需要的时间），即通常意义上的交付时间也相对较短。正是因为DevOps能够给企业带来的诸多益处，目前，DevOps已经成为企业软件研发的主流，被众多企业所采用。报告显示，超半数企业使用DevOps的敏捷工程实践管理开发项目，近6成企业选择编码规范、单元测试和持续集成。然而，虽然众多企业都期望DevOps能够给它们带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践DevOps依然是一个难题。在报告中，实际能够真正成功实施DevOps的企业仅有31.65%，另外，还有接近四成（41.13%）的企业居然不清楚自己是否成功实施DevOps，这不得不说是一个令人感到意外的结果。而当我们认真研究当前中国企业的DevOps现状时，就会明白这个结果也在情理之中。当前，虽然国内应用DevOps的众多，DevOps已经在国内逐步落地实践，但大部分企业仍然位于DevOps能力成熟度初始级和基础级，其比例高达7成。而在DevOps的细分领域，例如DevOps的敏捷开发管理成熟度方面，同样是近七成企业仍然处在基础级和全面级，仅有1.83%的企业处于卓越级。而且虽然大多数企业企业普遍采取了敏捷开发方法以提升研发效率，但敏捷开发技术普及率有待提升，研发管理流程严谨性不足。同样，在应用设计方面和安全风险管理方面，多数企业也是位于初始级和基础级。同时，在持续交付方面，企业的自动化测试整体覆盖率普遍偏低；在技术运营方面，企业整体运营能力有待提高，缺乏对潜在风险的管理。再加上企业中有近7成的的研发人员DevOps经验少于1年，在这样的情况下，得到上述的调查结果也就不足为奇了。总之，从报告来看，目前国内大多数企业的DevOps应用还是处在初始级和基础级的阶段，需要向全面级、优秀级、卓越级转变。而要实现企业DevOps从初始级、基础级向全面级、优秀级、卓越级转变，除了企业要增强对于DevOps的重视度之外，选择合适的DevOps工具和技术就显得至关重要了。而从报告中显示，近九成的企业会选择云来助力DevOps实践落地，这是因为，DevOps就是在开发和部署周期中设计开发人员需要的环境的自动化，以最大限度地减少开发人员的等待时间，并允许开发人员在代码基础上获得更多的迭代。考虑到这些环境一直处于变化状态，因此，DevOps是基于云计算的天然盟友，在云计算的支撑下企业能够立即启动支持开发和部署过程中涉及的各种环境所需的资源以实施DevOps。同时，在易用性、可伸缩性和性能方面有着卓越表现的微服务，成为了企业软件开发最受欢迎的架构，而微服务和DevOps有着非常密切的联系。微服务在具有众多优势外也带来了实施上的复杂性，整个系统由单一应用拆分为多个服务，微服务之间存在较强的依赖关系，服务之间如何协作如何处理就变得非常复杂。由于微服务是一个网状分布的，有很多服务需要维护和管理，对它进行部署维护和监控管理的时候就比较复杂。因此使用微服务，第一步是要构建一个一体化的DevOps平台。DevOps包含了持续集成与持续发布，服务依赖关系管理，服务的发现与负载均衡，以及集中化监控管理，这些都是微服务生态系统所必不可少的工具和实践。而近几年火热的容器技术也被誉为是DevOps的天作之合，它的出现使DevOps落地实践相对容易，而保持跨环境的一致性和灵活的可移植性是企业选择容器的主要因素。这些调查结果表明，大多数企业在DevOps实践过程中，基于云计算、微服务、容器给企业带来的诸多益处，都会选择云+微服务+容器的方式来具体落地DevOps。而在具体的工具选择上，国外厂商的产品仍然占据大半江山，JIRA在需求和项目管理领域拔得头筹、Gitlab位居代码管理首位。虽然国外老牌传统工具JIRA仍然以52.13%的市占率高居DevOps工具选择之首，但与云结合的DevOps工具的发展势头良好，国内厂商也在其中占据了一席之地，特别是在软件开发一体化管理领域，排名前两位的分别是国内公有云大厂华为云DevCloud与阿里云效，分别占据16.46%与10.98%的市场份额。尽管从整体上来看，软件开发一体化的DevOps平台目前在市场中的占有率仍然偏低，但从未来发展的趋势来看，与云结合的一体化DevOps将是未来DevOps平台发展的一个重要方向，这从报告中的企业广泛选择云以及与云计算有着紧密联系的微服务架构和容器可以得到很好地佐证。而在这个领域，之所以中国厂商能够占据领先的地位，和两家厂商在中国公有云市场的强势发展是分不开的。特别是华为云DevOps之所以能够成为报告中唯一占据一个首位的DevOps工具，首先应该得益于华为30多年软件研发的沉淀，这些在多年软件研发中积累的丰富经验，使得华为深知开发者到底需要怎样的DevOps工具，在这样的理念上推出的DevCloud，受到企业和开发者的青睐，自然就是水到渠成的事情了。其次，华为云DevCloud针对需求变动频繁、开发测试环境复杂、多版本分支维护困难、无法有效监控进度和质量等开发者研发中的普遍痛点，使开发人员实现软件研发过程可视、可控、可度量，还可以实现一键式部署，解决开发者在应用部署方面的挑战。而云端代码检查、自动化测试管理和APP测试功能，能够显著避免代码出错情况的发生，分布式代码托管功能更是为开发者的代码提供了一个可靠的“家园”。第三，华为云DevCloud不仅对外服务，其本身就孵化于华为内部的软件研发能力中心，至今还在为内部所有软件研发人员服务，在可用、可靠、安全性方面都经过了实践应用的检验。这些优点汇聚起来，得到这样的结果也就在情理之中了。实际上，从本质上讲，DevOps 不只是一种技术或方案，它更多的是文化，它重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作，以提高整个软件开发生命周期的效率以及质量。因此，谁拥有更多的开发者，谁更加了解开发者，谁就能更加准确的掌握开发者的需求，引领软件工程能力的趋势，也能做出更加接地气的产品，谁更新迭代的速度更快，谁就越有可能在未来的长跑中获胜。虽然从此次调查结果来看，国外厂商的DevOps产品仍然处于领先地位，但我们相信，在以华为云为代表的国内厂商的共同努力下，我国的软件工程能力将会得到显著的提升，我国的DevOps产品的能力也会得到迅速的提高，从而帮助中国企业落地DevOps，推动中国企业从DevOps的初始级和基础级的阶段，向全面级、优秀级、卓越级转变，全方位的促进国内软件产业发展，打造软件产业发展新模式，推动中国软件产业不断向前发展。                                                                                                                                                                  转载自：云计算开源产业联盟

转载自：CSDN博主「华为云」的原创文章原文链接：https://blog.csdn.net/devcloud/article/details/106492124【摘要】 云原生应用时代，如何集中团队力量在业务场景设计和实现，从而最大化软件研发ROI？如何利用云服务厂商，高效率低成本的开发高性能高可靠的微服务应用？                   “未来的软件一定是生长于云上的”1. 云原生时代的应用云原生时代，随着容器技术、微服务架构思想、产品研发运营模式不断地推陈出新和迅速发展，应用的设计和开发落地门槛已经降低到了历史低点。根据国际知名数据咨询公司IDC（国际数据公司）的调查研究表明，从2018年到2023年将有超过500,000,000个应用被创建，这个数字是过去40年所有创建应用的总和。另外，在IDC于2020年2月发布的《IDC FutureScape: 全球云计算2020 年预测——中国启示》中显示，云原生应用所影响的领域正逐渐从互联网走向非互联网，从传统应用升级走向云原生。当下，云原生技术的成熟正极大地影响着个人、企业乃至整个社会的生产生活方式。下面是几条与云原生应用强相关的预测内容：分布式云：到2021年，中国90%以上的企业将依赖于本地/专属私有云、多个公有云和遗留平台的组合，以满足其基础设施需求。API生态：到2023年，90%的新数字服务将使用公有云和内部API提供的服务构建复合型应用程序；其中一半将利用人工智能（AI）和机器学习（ML）。多云管理：到2022年，50%的企业将部署统一的VMs、Kubernetes和多云管理流程和工具，以支持跨本地和公有云部署的多云管理和治理。云堆栈扩展：到2024年，10%的企业内部工作负载将由公有云服务商数据中心以外的、位于客户数据中心和边缘位置的公有云堆栈提供支持。超敏捷APP：到2023年，50%的中国企业应用将部署在容器化的混合云/多云环境中，以提供敏捷的、无缝的部署和管理体验。在这场应用的变革中，越来越多的应用所有方会将应用基础设施交由更加专业的公有云/混合云服务商进行管理，通过API的方式对基础设施进行管理，由服务商提供更加敏捷和无缝的部署管理功能。如此，应用所有方可以将更多的投资及人力投入聚焦到应用本身的业务逻辑设计、开发、运维和体验优化，大大减少了产品上市的时间并得到了更高的可伸缩性，使应用开发的ROI（投资回报率）最大化。2. 使用微服务架构构建云原生应用云原生应用的定义有多种版本，最早为2015年pivital提出了云原生应用的定义，随后CNCF在2015年也对云原生应用进行了定义，2018年进行了重定义，具体定义可以参考kubernetes-handbook。可以发现自从云原生的概念出现，微服务架构就是云原生应用中浓墨重彩的一部分。这一节里会讲到微服务架构使用场景，微服务应用在整个应用技术栈中的位置，和开发一个微服务你需要做的事情。2.1. 使用微服务的场景构建云原生应用，首先一定是企业或者个人想要最大程度将自己的时间和精力从复杂的底层依赖开发维护中解放出来，集中在业务场景的设计和实现上，并且能够独立解耦的自动化完成应用各个模块的开发落地。这意味着独立开发的某一模块或负责某一单独业务的开发者，会最大程度的利用云厂商提供地DevOps工具链完成整个应用开发运维的共同目标，这样大家可以轻松地将应用作为一个松耦合的服务集合快速发布和更新，降低成本的同时也更容易避免单点故障。2.2. 微服务应用在技术栈中的位置假设应用所有者已经做好了微服务的业务设计，我们来看看在落地阶段，微服务应用在产品研发和运行中的位置：红色部分为微服务应用的核心模块，是由应用所有者开发和维护地运行时微服务应用。随着业务的增长，受系统能力影响，为了提高微服务的高可用、可靠性以及韧性，需要对微服务进行治理。常见的治理手段有：负载均衡、熔断、限流、降级、容错和隔离等，篇幅有限这里不加赘述。黄色部分从左到右代表从Dev到Ops的技术栈。首先，应用开发者需要根据应用类型，选择依赖的微服务开发框架（chassis），使用框架时可以通过添加注解的方式，处理微服务运行时面临的横切面问题（crosscutting concern），比如：日志框架（log4j/logback）、健康检查、metrics、分布式追踪等。其次，编码完成后，可使用云服务厂商提供的DevOps工具链能力实现代码的归档、编译构建、发布部署等能力，将微服务部署在运行环境中。最后，还可以利用云服务厂商提供的运维能力对微服务进行运维监控。一般来说，云服务厂商提供的应用平台能力也是独立而解耦的，应用所有者可根据自己的需求和预算来自定义选择自己需要的服务。紫色部分是运行时技术栈，蓝色箭头代表流量的流向。当微服务部署运行起来后，流量会从各种客户端首先连接到入口（比如服务网关/ELB），同时，流量在这里会根据请求特征分发到各个对应的业务处理微服务，随后对请求进行一系列的处理，返回结果。微服务的运行还依赖了很多中间件，比如：缓存、消息等；还有一些微服务的功能特性，比如：服务网格、服务注册发现等，这些中间件或特性也都由框架或者云服务厂商提供。微服务和中间件等其实都是上层服务部署在基础设施上，比如：虚机、容器或CCI实例。 综上所述，一个应用的落地其实涉及到很多技术和场景，使用微服务架构开发应用可以最大程度的简化应用所有者对底层设施和中间件的管理运维，通过自定义使用云服务厂商提供地全场景、端到端的应用平台能力，将资源聚焦在业务创新和落地上（红框部分）。3. 实践 - 一元体验all above最后，华为云CSE微服务平台提供了以ServiceComb开源框架拖底的配置中心和服务中心，提供动态配置和可靠的服务中心服务。ServiceComb服务中心在华为内部的大规模生产实践（支撑华为商城运行），支撑起数十万级别的tps的服务集群，可靠性得到了充分的验证。

文作者：乔雷  原华为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-native2. 华为云如何使能云原生应用以下这张图，来自我画的一张Huawei Cloud Enables Cloud-Native Applications的PPT，重点讲解华为云如何使能云原生应用。我引用在这里供大家参考和探讨。概要解释如下：服务开发者使用华为云的软件开发云(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画了一张更详细一点的，供参考。如下： 原文地址：https://bbs.huaweicloud.com/forum/thread-8355-1-1.html

调用微服务接口时10次中会有1到2次报SSL握手超时错误，查询了下相关问题，怀疑是netty工作线程数不足导致，请问microservice.yaml中是否可以配置线程数来解决这种问题。PS：[2020/03/17 19:47:01.637][ERROR][fetchAllRegionDataJson occurs error, json=null][com.***.***.***.***.util.rest.LocalRestHelper][fetchAllRegionDataJson,187][https-jsse-nio-8.35.41.171-32250-exec-96]org.apache.servicecomb.swagger.invocation.exception.InvocationException: InvocationException: code=490;msg=CommonExceptionData [message=Cse Internal Bad Request]at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.doCreate(ExceptionFactory.java:79) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.convertException(ExceptionFactory.java:124) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.swagger.invocation.exception.ExceptionFactory.convertConsumerException(ExceptionFactory.java:83) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.swagger.invocation.Response.createConsumerFail(Response.java:129) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.swagger.invocation.Response.createFail(Response.java:122) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.swagger.invocation.AsyncResponse.fail(AsyncResponse.java:42) ~[swagger-invocation-core-1.2.1.jar:1.2.1]at org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.fail(RestClientInvocation.java:254) ~[transport-rest-client-1.2.1.jar:1.2.1]at org.apache.servicecomb.transport.rest.client.http.RestClientInvocation.lambda$invoke$0(RestClientInvocation.java:106) ~[transport-rest-client-1.2.1.jar:1.2.1]at io.vertx.core.http.impl.HttpClientRequestBase.handleException(HttpClientRequestBase.java:139) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.HttpClientRequestImpl.lambda$null$8(HttpClientRequestImpl.java:505) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:320) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.impl.EventLoopContext.execute(EventLoopContext.java:43) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:188) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:180) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.HttpClientRequestImpl.lambda$connect$9(HttpClientRequestImpl.java:504) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.HttpClientImpl.lambda$getConnectionForRequest$5(HttpClientImpl.java:978) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.ConnectionManager.lambda$getConnection$7(ConnectionManager.java:155) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.pool.Pool.connectFailed(Pool.java:364) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.pool.Pool.access$600(Pool.java:86) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.pool.Pool$Holder.lambda$connect$0(Pool.java:128) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.impl.FutureImpl.tryFail(FutureImpl.java:170) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.HttpChannelConnector.connectFailed(HttpChannelConnector.java:253) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.http.impl.HttpChannelConnector.lambda$doConnect$0(HttpChannelConnector.java:162) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.net.impl.ChannelProvider.lambda$connect$1(ChannelProvider.java:81) ~[vertx-core-3.7.0.jar:3.7.0]at io.vertx.core.net.impl.ChannelProvider$1.userEventTriggered(ChannelProvider.java:113) ~[vertx-core-3.7.0.jar:3.7.0]at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:344) ~[netty-transport-4.1.45.Final.jar:4.1.45.Final]at io.netty.channel.AbstractChannelHandlerContext.invokeUserEventTriggered(AbstractChannelHandlerContext.java:330) ~[netty-transport-4.1.45.Final.jar:4.1.45.Final]at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:322) ~[netty-transport-4.1.45.Final.jar:4.1.45.Final]at io.netty.handler.ssl.SslUtils.handleHandshakeFailure(SslUtils.java:347) ~[netty-handler-4.1.45.Final.jar:4.1.45.Final]at io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2004) ~[netty-handler-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) ~[netty-transport-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.45.Final.jar:4.1.45.Final]at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242]Caused by: javax.net.ssl.SSLHandshakeException: Failed to create SSL connectionat io.vertx.core.net.impl.ChannelProvider$1.userEventTriggered(ChannelProvider.java:111) ~[vertx-core-3.7.0.jar:3.7.0]... 14 moreCaused by: javax.net.ssl.SSLException: handshake timed outat io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2001) ~[netty-handler-4.1.45.Final.jar:4.1.45.Final]

 关于Apache ServiceCombApache ServiceComb 是开箱即用、高性能、兼容流行生态、支持多语言的一站式开源微服务解决方案，也是Apache基金会毕业的首个开源微服务框架。华为云的应用管理与运维平台ServiceStage，微服务引擎CSE均对ServiceComb提供很好的支持。云资源代金券免费领取2020.3.16~2020.3.25期间，用户可点击该链接免费领取一张100元云资源代金券。（链接会在活动开始时贴在此处）动手实验室Codelab互动活动 Codelab《一键式20分钟开发“体质指数”微服务应用》链接 将向你展示如何使用ServiceComb-Toolkit工具根据OpenApi契约一键式生成微服务脚手架，在规范开发流程的同时，实现微服务应用的快速开发。现在完成该Codelab，讲完成结果截图回帖，并回复互动话题，就可以赢取奖品。互通话题1、 你在实践微服务架构中遇到的痛点有哪些？2、 你最看重的微服务框架的能力（易用性，功能完善，高性能，生态兼容性，多语言支持性，开发效率等）有哪些？请说明原因。3、 你认为ServiceComb-Toolkit的如何发展会更加有利于提升你微服务应用的开发效率？参与方式直接在本帖回复codelab完成截图，并加上关于以上3个问题中的任意问题的理解或评论，欢迎大家多从自己实践经验的角度分享。本期奖品回帖参与本次讨论，回复与话题相关的原创内容，即可获得精美3合一数据线（总数量为8个，按回帖顺序先到先得)。（奖品于活动结束后邮寄发放，需提供地址，会通过站内信收集)

springboot2.0.X整合CSE是可以了，但是我们需要springboot2.1.X，缺发现启动一直报错，以下是错误信息：Exception in thread "main" java.lang.AbstractMethodError: org.springframework.boot.context.config.ConfigFileApplicationListener.supportsSourceType(Ljava/lang/Class;)Zat org.springframework.context.event.GenericApplicationListenerAdapter.supportsSourceType(GenericApplicationListenerAdapter.java:81)at org.springframework.context.event.AbstractApplicationEventMulticaster.supportsEvent(AbstractApplicationEventMulticaster.java:295)at org.springframework.context.event.AbstractApplicationEventMulticaster.retrieveApplicationListeners(AbstractApplicationEventMulticaster.java:225)at org.springframework.context.event.AbstractApplicationEventMulticaster.getApplicationListeners(AbstractApplicationEventMulticaster.java:196)at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:133)at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:127)at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:76)at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:53)at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:342)at org.springframework.boot.SpringApplication.run(SpringApplication.java:305)at org.springframework.boot.SpringApplication.run(SpringApplication.java:1215)at org.springframework.boot.SpringApplication.run(SpringApplication.java:1204)at com.github.yhs0092.javachassis.demo.AppMain.main(AppMain.java:11)