基于华为云ServiceStage的微服务DevOps实践

举报
学大大 发表于 2019/11/26 11:43:06 2019/11/26
【摘要】 华为云微服务产品经理刘云华分享与展示ServiceStage的微服务DevOps

基于华为云ServiceStage的微服务DevOps实践

刘云华  微服务产品经理

大家好,我最近两年的工作是帮助开发者更好的去开发微服务和管理自己的应用,今天分享的主题是微服务,2011年的时候就开始跟进这一技术,2013年后开始在公司内部做一些验证,在一些产品线里面去试点,2014年开始在公司内部开始大规模应用,包括华为云终端,比如华为手机上的APP后端全部基于华为云服务,AI,5G的一些核心的系统,华为云不仅在互联网行业,在传统行业,如政府、能源、制造等行业应用也比较广泛。

今天主要分享三块内容,主要包括:

1.  为什么需要微服务?

2.  华为云服务解决方案概览

3.  基于华为云ServiceStage的演示

现场调研发现,用微服务的公司有一小部分,今天的演讲不会对微服务的概念和基础作过多解释,这些信息可通过网络和其他消息推送了解。接下来就从三块主题开始。

一、为什么需要微服务

1.  业务的变革与创新

image.png

(1)   传统业务数字化,云化已成为不可逆转的趋势;如银行、政府等

(2)   针对应用来说,流量的不可预知性已成为互联网应用常态;如618、双11购物节

2.  应用架构的变迁:

应用向CloudNative演进,微服务是CloudNative的事实标准

image.png

(1)   单体架构


  特点:

l  紧耦合;

l  系统复杂、错综交互;

l  完全封闭的架构;

(2)   SOA架构

  特点:

l  松耦合;

l  通常通过ESB(通信总线)进行系统集成;

l  有状态;

l  大团队:100~200人;

l  TTM:1年、半年、月;

l  集中式、计划内停机扩容;

(3)   微服务架构

  特点:

l  解耦;

l  小团队:2 Pizza Team;

l  TTM:按天、周进行升级发布;

l  DevOps:CI,CD,全自动化;

l  可扩展性:自动弹性伸缩;

l  高可用:升级、扩容不中断业务;

未来一定是几种应用架构相互结合的,不会是单一的,根据具体应用场景找到适合的架构。

3.    微服务带来的好处和挑战

根据哲学,事物具有两面性,那么,我们来看一下微服务的好处和不足。

image.png

好处:

(1)   服务模块的边界更清晰:微服务强调模块化结构,这对大型团队非常重要;

(2)   支持独立部署:简单服务更易部署,由于服务是自治的,出现问题之后不会引起系统崩溃;

(3)   允许技术多样性:有了微服务,可以混合使用多种编程语言,开发框架和数据存储技术;

挑战:

(1)   分布式编程难度大、有风险:分布式系统编程难度更大,远程调用更慢且总存在失败风险;

(2)   需处理分布式系统的一致性:对于分布式系统来说,保持一致性非常困难,意味着大家都要处理最终一致性;

(3)   增加运维复杂性:需要一个成熟的运维团队(机制)来管理大量需要频繁部署的服务;

二、华为云微服务解决方案概览

华为云微服务解决方案=咨询+框架+平台+工具+生态

框架包括:ServiceComb(开源开发框架)、Spring Cloud、ServiceMesh、Lstio;

首先作云服务开发需要一个开发框架,然后就是运维管理,包括生命周期管理、微服务管理、微服务治理等,生命周期管理包括:部署/卸载、启动/停止、升级/回滚、弹性伸缩等;微服务管理:契约管理、注册中心、配置中心等。其次是工具(CPE),接触过很多公司所需要的微服务并不是解决一个单点问题,也不单单是一个工具,他们更多的是需要微服务的这套理念,来改革自己整个研发的流程、技术、包括研发组织,基本上是一个体系化的变革,所以除了开发框架、运维管理和工具之外,华为云还提供一些微服务咨询服务,告诉使用者怎么去做微服务以及业务是否适合做微服务,有些业务单点效率更高,所以并不是所有架构都需要做微服务,以及做完微服务还需要用到哪些东西等等,因此,咨询服务可以帮助一个企业少走很多弯路。

再者更为几点重要的就是工具生态,很多工具功能很多但是不太好用,所以很多企业需要定制化的工具,一个比较好的工具或者想法可以在工具市场里面共同构建或者发布。另外就是微服务的组件市场,很多企业的诉求是通过业务共享自己的业务组件,以前通过原始的代码复制,再到组建的方式共享,现在则希望通过服务化的方式来共享,即通过微服务的方式来共享,一个部门在各方面做一个公共的微服务,在公共业务方面则不需要自己去独立开发代码,只需要调用操作接口即可。

平台包括:弹性云服务器平台、容器云平台和Serviceless云平台。

image.png

微服务解决方案详解(1/4):微服务框架

提供ServiceComb(开源开发框架)、Spring Cloud、ServiceMesh、Lstio多种解决方案,分别适用于不同的场景,降低企业迁移成本。

优势:

l  API First

支持基于Swagger的API管理

l  多语言微服务

支持JAVA,GO,.Net,PHP,python等

l  技术开放

  支持ServiceComb、Spring Cloud和ServiceMesh

image.png


微服务解决方案详解(2/4):微服务生命周期管理

image.png


微服务解决方案详解(3/4):微服务DevOps

image.png

基于ServiceStage流水线实现应用全流程“自助式”开发、集成、验证与上线

优势:

l  一键生成持续交付环境

自动生成应用框架代码、构建、部署及测试环境

l  多语言应用

JAVA、Go、node.js、php、python、Ruby、.net

l  多种源码仓库

CodeHub、GitHub、Gitee、GitLib、Bitbucket

微服务解决方案详解(4/4):微服务治理

image.png

适用于电商、游戏、教育、媒资、能源及金融等有明显波峰波谷场景的应用,可以实现分布式系统细粒度治理和高可用保障

优势:

l  低门槛

通用治理能力沉淀到框架,开发人员只需聚焦业务

l  简单易用

提供GUI一站式治理控制台

l  准实时

运行状态实时监控,配置下发实时生效 

三、基于华为云ServiceStage的演示

场景(1/5):新应用开发

我们是一家新成立的创业公司,急需推出一款新的应用,这款应用采用微服务设计架构,当前微服务划分已经完成,需要立即开始编码。

Case1:  一键式搭建新微服务开发环境

Case2:进行业务开发,通过流水线持续发布

流程:华为云官网产品开发者开发者平台应用管理与运维平台ServiceStage立即使用,基础版可免费使用20个实例,选择北京四,在主界面有典型场景的引导页面,可以帮助大家更好的去熟悉系统。

持续交付工程创建云上工程基于模板创建微服务选择语言选择框架部署系统配置信息(项目名称和代码来源)仓库组织部署集群集群命名空间实例个数

image.png

场景(2/5):开发环境搭建

应用上线之后,业务稳步增长,开发团队也随之扩展,不断有新同事加入,新来的同时进来之后需要快速搭建自己的开发环境。

Case3:一键式搭建已有代码微服务开发环境

Case3操作和之前的场景1操作类似,不同的是选择已有模板搭建自己的开发环境。

场景(3/5):Web应用上云

为了加速扩大市场份额,经公司股东同意,收购一个音乐App,叫做Spring Music,这是一个基于Java+js+springboot技术构建的单体应用,希望能快速迁移到ServiceStage上来,进行统一运维管理,降低成本。

Case4:  自定义构建任务

Case5:应用部署及生命周期管理

主要有两种构建:①基于ARM的构建;②基于通用的构建;

image.png

场景(4/5):微服务注册与发现

随着产品类别的不断丰富,以及不同技术背景的同事的加入,研发团队也引入了多种微服务技术栈,包括有ServiceComb,Spring Cloud以及Service Mesh。能否通过一个平台管理多种技术栈呢?

Case6: ServiceComb微服务注册与发现

Case7:Spring Cloud微服务注册与发现

Case8:Service Mesh微服务注册与发现

场景(5/5):微服务治理

随着业务量的飞速上涨,以及各种营销活动的开展,我们需要一个强大的控制台来实时监控和治理整个微服务系统在海量流量下的各种问题。

Case9: 微服务负载均衡

Case10:微服务降级

Case11:微服务容错

Case12: 微服务熔断

Case13:微服务错误注入

Case14:微服务黑白名单

Case15: 微服务灰度发布

Case16:微服务压测

Case17:微服务限流

四、Q&A

Q:假如我有两个微服务模块,分别为微服务A和微服务B,如果微服务B调用了微服务A的模块,当作集成的时候,如果微服务A接口发生变化,如何让B知道微服务A的变化和如何去测试这个变化?

A:这个问题问得很好,是大多数研发里面经常会遇到的一个问题,和传统的研发一样,其他的调用发生变化会使系统的调用发生问题,其实这个问题没有很好的解决办法,主要有以下解决方法:可以在整个部门里面加入条件约束,因为这个改变是一个十分恶劣的事情,所以加强团队的管控可以有效的避免这一问题;另一方面,在整个框架里面做一个契约优先,在做微服务框架之前,首先做一个契约,之后再写代码,依赖契约去做调用,然后契约在同一个地方管理,可以保证擅自改变会被发现,一般由架构师实现契约的管理,在框架内部也会自动识别,测试时如果调用不了就会自动报错。因此,在一个团队里面遇到这种问题主要是通过管理的手段解决,通过技术方式是很难解决的。

 

视频演讲地址:https://mp.weixin.qq.com/s/AcowdhSMKWmS22UfWhSegQ


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。