-容器教科书-系列第一讲：【容器教科书】创刊首航！               3个月前，一篇名为《你的同龄人正在抛弃你》的文章火遍了大街小巷，互联网的每一个角落都呼唤着那个传奇——同龄人。    同龄人是谁，我们已经不得而知了。为了不被他们再一次抛弃，小编作为一个有良知、有自信、有责任心的良好青年，决定用自己潜心修炼的结果帮助大家！    俗话说360行，行行出状元。如今，各行各业别说状元，探花都挤满了人。怎么办？急，在线等。经过长期在技术领域的蛰伏，我终于发现了点儿什么！真相就是——容器技术！    时下，容器技术火到没朋友，Docker、K8s的发展速度让人瞠目结舌！赞叹之余，就不能想想从中可以获得些啥机会吗？    嘿嘿，这个世界总是在默默的奖励那些不断学习的人。小编看各位朋友骨骼惊奇，一看就知道是学习容器技术的练武奇才，维护互联网正义与和平的任务就交给你们了好不好？学习三步走！海陆空360度全方位贴身辅助！1第一步：容器教科书·删繁就简，手把手让你成为容器大师！华为云容器大咖潜心钻研，终于制定出详尽的“容器大师速成秘笈”，PPT手把手教学！容器技术轻松Get，妈妈再也不用担心我的学习！学习也能美滋滋。2第二步：随堂练习·好记性不如烂笔头！高考级针对性的命题帮助你海陆空360度全方位无死角的掌握容器知识。俗话说，好记性不如烂笔头，多做练习，成为容器大师不再是梦想！老师经常说我们，一看就懂，一学就会，一做就错。我们要勇敢Say NO！没有练习可还行？配合容器教科书的学习资料，我们推出了非常优秀的随堂练习！保证海陆空360度全方位无死角的打击知识盲点，堪称高考命题级呢！3第三步：兴趣宝典·大咖直播秀，容器技术新鲜干货抢先尝！    通过Cloud Native Lives系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。    讲师团队主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。    系列直播传送门：https://bbs.huaweicloud.com/forum/thread-9573-1-1.html    关注【容器教科书】系列资讯，定期完成随堂实践，时刻关注大咖精彩直播，假以时日，相信您一定可以成为容器领域的专家！    最后，文末附上首期《Docker培训教材》PPT以及随堂实践作业一份，感兴趣的朋友可以尝鲜了解啦~Docker培训教材.pdf( 预览 )课程一课后实践.pdf( 预览 )

本期【云享专家·微话题】由云享专家Tsjsdbd与大家一起讨论“容器与虚机，谁将主宰云世界”，希望大家能够畅所欲言。如果大家有其他任何与PaaS相关的问题，也可以在本帖回复直接咨询云享专家Tsjsdbd。 =======【云享专家·微话题】容器与虚机，谁将主宰云世界？=======如今Docker容器技术已经比较普及，在各个领域都开始发挥出价值。并且容器与虚拟机十分和谐的共存，两者各自具有不同的特征和相应适合的应用场景。然而，渐渐地你会发现在各个云基础设所涉及的领地，容器正在以它的角度重建这个世界，容器存储，容器网络，容器调度都全部长出自己的枝干。在实际的领域，容器也开始崭露头角，HPC，基因测序，边缘云，微服务等等。相信有一天，容器会与虚机平起平坐，然后在那之后，迅速超越，成为云计算的中流砥柱。Container will Rebuild the World。每个人对“容器与虚机”都有不一样的理解，今天我们就“容器与虚机”一起来讨论，希望看到大家精彩的评论：1、讲讲你在容器使用过程中存在的问题？2、讲讲容器技术如何在各个技术领域渐露头角？3、容器一直被诟病的薄弱点安全相关进展？4、你觉得容器是否和虚机的各自发展前景？微话题活动：参与本次微话题讨论，有机会获得优质评论奖活动时间：2018年7月16日-7月27日参与方式：直接在本帖回复你关于以上4个问题的理解或评论获奖方式：活动结束后，将由云享专家Tsjsdbd选取出3名优质评论奖，各送出《Docker 容器与容器云》书籍1本。

比满减更有诚意比代金券更实在华为云 · 容器体验馆劲爆开张啦基础套餐0元领用创建集群、升级业务从初级到进阶，让你的容器技术3日超神活动时间：7月10日——9月30日活动对象：所有华为云注册用户参与方式：点击下方链接进入体验馆（免费期3天，到期后会自动删除集群，不会扣费）          https://console.huaweicloud.com/cce2.0/#/app/guidance/list?fromforum举例：以创建集群为例，简单几步即可创建成功1、 点击立即体验，进入 “创建虚拟机集群”，前2步已为您配置默认参数（创建虚机不收费）2、 设置密码或秘钥对，此处以密码为例3、 点击 提交订单 ，在 资源管理 中可查看已创建的集群，并进行管理4、 创建成功后，即可体验容器服务更多功能是不是简单好用又功能强大呢速来抢占体验名额！

报名链接：http://www.huodongxing.com/event/4444348140300?fromlt 北京站直播传送门：http://www.itdks.com/dakashuo/playback/2325 Cloud Native Days中国巡回Meetup北京----上海----广州，连续三站享不停 关于Cloud Native DaysCloud Native Days 专注于云原生领域的技术探讨和前沿趋势挖掘。本次北京、上海、广州三地连办，邀请了来自CNCF、华为、IBM、微软、VMware、Ebay等业界权威机构的专家讲师进行专题分享，诚邀您参加Meetup，与云原生技术大咖零距离交流。 精彩议程 第一站——北京 6月29日3W 咖啡—北京海淀区海淀西大街70号101室 第二站——上海 6月30日世界广场路演中心—上海浦东南路855号 世界广场B2 第三站——广州 7月1日3W 咖啡·天誉青创社区—广州天河区林和中路第136号天誉花园二期 大咖云集17987 Quinton HooleCNCF技术监察委员会（ToC）委员Kubernetes指导委员会委员华为云技术VP为华为包括公有云、私有云、边缘云、物联网、PaaS、IaaS和SaaS提供技术指导。曾是AWS EC2的创始工程师之一，发起并领导了EC2前5年的早期设计、开发和产品化工作。此外，Quinton曾担任Google广告SRE团队的技术主管和高级经理，是早期Google Cloud Kubernetes团队的技术负责人之一，并曾在金融服务、电信和IT行业的多家初创公司担任技术负责人 17988 Keith ChanCNCF中国区总裁Linux基金会亚太地区的战略规划主管拥有20多年IT行业经验，2009年起从事开源相关工作。曾帮助多家大中华区公司包括政府、银行、金融机构、高科技企业等优化提升开源管理架构和战略规划。 Keith Chan先生目前还负责Linux基金会在大中华地区的开源推广工作。 17989 马达Kubernetes MaintainerSIG-Scheduling co-LeaderIBM中国系统部软件架构师 17990 张海宁VMware中国研发先进技术中心技术总监 Harbor企业级容器镜像仓库开源项目创始人 17991 倪朋飞微软软件工程师Kubernetes项目维护者 17992 张超盟华为云微服务平台架构师 17993 李建强eBay容器云平台组security sig lead 17994 邓宇星 Rancher Labs大中华区研发主管 17995 任玉泉 Caicloud 高级开源工程师 主办单位 CNCF 华为云 合作伙伴百格 IT大咖说 K8S中文社区 活动答疑 Q:怎么报名长按扫描下方二维码即可报名 Q：怎么确认报名是否成功？报名成功后，系统会自动发送报名成功提示信息，，入场时凭信息签到即可 Q:Meetup有交流群吗？如何加入？添加工作人员微信（putong3333）即可，TA会邀您入群

报名链接：http://www.huodongxing.com/event/4444348140300?fromlt 北京站直播传送门：http://www.itdks.com/dakashuo/playback/2325 Cloud Native Days中国巡回Meetup北京----上海----广州，连续三站享不停 关于Cloud Native DaysCloud Native Days 专注于云原生领域的技术探讨和前沿趋势挖掘。本次北京、上海、广州三地连办，邀请了来自CNCF、华为、IBM、微软、VMware、Ebay等业界权威机构的专家讲师进行专题分享，诚邀您参加Meetup，与云原生技术大咖零距离交流。 精彩议程 第一站——北京 6月29日3W 咖啡—北京海淀区海淀西大街70号101室 第二站——上海 6月30日世界广场路演中心—上海浦东南路855号 世界广场B2 第三站——广州 7月1日3W 咖啡·天誉青创社区—广州天河区林和中路第136号天誉花园二期 大咖云集17996 Quinton HooleCNCF技术监察委员会（ToC）委员Kubernetes指导委员会委员华为云技术VP为华为包括公有云、私有云、边缘云、物联网、PaaS、IaaS和SaaS提供技术指导。曾是AWS EC2的创始工程师之一，发起并领导了EC2前5年的早期设计、开发和产品化工作。此外，Quinton曾担任Google广告SRE团队的技术主管和高级经理，是早期Google Cloud Kubernetes团队的技术负责人之一，并曾在金融服务、电信和IT行业的多家初创公司担任技术负责人 17997 Keith ChanCNCF中国区总裁Linux基金会亚太地区的战略规划主管拥有20多年IT行业经验，2009年起从事开源相关工作。曾帮助多家大中华区公司包括政府、银行、金融机构、高科技企业等优化提升开源管理架构和战略规划。 Keith Chan先生目前还负责Linux基金会在大中华地区的开源推广工作。 17998 马达Kubernetes MaintainerSIG-Scheduling co-LeaderIBM中国系统部软件架构师 17999 张海宁VMware中国研发先进技术中心技术总监 Harbor企业级容器镜像仓库开源项目创始人 18000 倪朋飞微软软件工程师Kubernetes项目维护者 18001 张超盟华为云微服务平台架构师 18002 李建强eBay容器云平台组security sig lead 18003 邓宇星 Rancher Labs大中华区研发主管 18004 任玉泉 Caicloud 高级开源工程师 主办单位 CNCF 华为云 合作伙伴百格 IT大咖说 K8S中文社区 活动答疑 Q:怎么报名长按扫描下方二维码即可报名 Q：怎么确认报名是否成功？报名成功后，系统会自动发送报名成功提示信息，，入场时凭信息签到即可 Q:Meetup有交流群吗？如何加入？添加工作人员微信（putong3333）即可，TA会邀您入群

记得刚工作那会做了几个网站类项目，每次临近项目上线，都要拉到宾馆封闭开发，搬上几台小机，搭建开发、测试、类生产环境用，因为环境太复杂，每次都是PL们亲力亲为，生怕有一个环节出错就前功尽弃。开局就更是个体力活，扛机柜、搬服务器、架路由器、有些时候网线都要现做。现在想想也不知道是因为公司小，还是当时的IT界就这样，研发和服务其实没分得那么清楚。后来陆续换了一些公司和项目，肩挑手扛的开局慢慢的也有专门的服务团队来做，也就不再是当年研发一家亲的状态了。服务团队会要求我们的软件能快速批量部署，“部署、配置要能通过界面操作”、“要能静默安装”、“安装过程不需要人工干预”、“最好是预安装，机器上电就能用”。在那个年代的IT服务团队已经开始关注自动化、提升效率了。进入云计算1.0时代后，再也不用肩挑手扛的去搭建基础设施，只管从云上申请资源就好了。各云厂商为了吸引客户，也把原来线下平台软件搬上云，丰富这个池子里的资源，以满足用户日趋复杂的业务场景：WEB容器、云数据库、分布式缓存、监控、日志、审计等云上的资源越来越丰富。 在这些新服务的诱惑下，各种C什么O们也不再痴情于自研平台软件，而是直接使用云上服务，而对服务人员来说，运维的难度也就越来越大了，于是服务人员摇身一变开始转攻编程，写出行云流水般的脚本，让部署与日常的运维工作开始变得有序，可能还充满乐趣，这就是自动化的魔力，让我们解放双手的同时，还能取得精神上的满足。既然自动化如此神奇，各大厂商、组织也拿出浑身解数来迎合市场的需求，heat，kubernets，puppet，Chef，Ansible一大堆产品应运而生，各云服务也争相把API开放出来以便满足自动化的要求。如何让用户更方便的对资源、应用、中间件进行管理呢？前方高能。国内大厂推出了解决方案——华为云应用编排服务AOS（Application Orchestration Service）。它可对云上的应用、云中间件、传统的和容器化的计算、存储、网络资源进行统一的部署管理，并通过编排引擎，让用户可自行定义资源、应用间的依赖关系、引用关系等，实现一站式云资源开通和云应用的部署。AOS以华为云上的云服务为基本单位，对每个云服务对象定义了常用的输入、输出与周边依赖，使得用户很容易通过AOS的图形化设计器，将这些元素像画电路图一样，并联或串联起来，并基于设计的图形，一键“点亮资源”（申请资源，并使资源处于可用状态），真正做到 “让用户像用电一样享受云计算”。 图1：这么漂亮的图形化工具，你猜不同颜色的线代表什么意思？下面以典型的电商建站场景为例，看看AOS到底能帮助我们提升多少效率：在没有AOS编排工具前，我们至少需要进行10步操作才能完成，而且每种资源的开通申请，都要到各云服务的页面进行操作，整个过程是相当繁琐的：1、进入网络服务，申请VPC、Subnet2、进入网络服务的安全组页面，创建安全组3、进入弹性云主机服务，创建云主机并绑定EIP4、进入弹性负载均衡，创建ELB，并把云主机添加到ELB的监听范围内5、进入antiddos服务，给ELB的EIP开通antiddos服务，防止DDOS攻击6、进入RDS服务，创建RDS云数据库实例7、进入DCS服务，创建DCS分布式缓存的实例(上面这些还只是最基本的，有可能还需要开通云审计、云日志、云监控、CDN、共享存储等多个服务，来支撑业务系统的运行)8、手动把上面所有资源的信息纪录下来，以备安装应用时配置使用9、上传必须的软件包10、远程登陆到云主机进行安装、配置（看着简单的“安装配置”四个字，其中的辛酸又有多少人知道呢） 使用AOS自动化编排后，可把上面的步骤进行精简，当然要获取极致的自动化部署体验，个人推荐结合CCE（云容器引擎）服务一起使用，双剑合璧，整个过程会让人感受到前所未有的爽快：上面流程的1-7步，我们可以通过AOS模板一步完成，不再需要挨个云服务云申请资源。AOS汇聚了华为云上主流服务的创建、删除、修改API，用户无需再感知云服务的API，只需要按AOS提供的规范定义资源模型和模型间的关系，剩下漫长的开通资源的过程就交给AOS了。直接选取一个自己需要的容器集群进行部署 图2： 涵盖网络、虚机、容器、应用、中间件的样例模板，继续更新中… 图3：选择创建CCE容器集群 图4：创建集群常用的参数都已经自动填充，太贴心了 第8-10步，同样也是通过AOS样例模板一步搞定，我直接选取Magento的电商应用部署，当然如果用户部署的不是Magento的应用，需要手动修改一下模板。图5：选择容器应用的样例模板 图6：可直接进入设计器修改生成自已需要的模板 图7：也可直接进行部署 图8：应用各组件的部署进度、状态一目了然（PS: 示例模板应该是为了展示的便利和学习的方便，把整个场景分别放在了资源和应用两个样例里，真正使用的时候，可以把这两个模板拷到一个文件中，那么整个从底层资源到中间件，再到上层应用的部署，一个部署动作就能搞定）就是这么简单，一个CCE集群和一个基于容器运行的电商应用就出现在眼前了。至于门槛，主要是一些基础的行业知识，比如：· 需要了解yaml（一种比json更简洁的描述语言），写出来的模板不能有基本的语法错误，就像写json时大括号总得写对位置吧· 需要对所使用的云服务、对AOS封装的资源模型有一定的了解，比如创建VPC，你得知道什么是CIDR，创建安全组，你得知道是给TCP是UDP协议做规则，创建RDS您得知道HA与单机的区别吧。· 要清楚业务部署时的依赖关系和先后顺序，比如，要先把云主机创建好，然后开始部署应用AOS想尽办法降低门槛，除了提供上面所说的覆盖各种场景的样例模板外，还为提供了可视化的模型设计器，就好比编程时有了可以直接copy的代码sample，还得有个好用的IDE，这样会大大简化模板的开发，0基础也能快速开发、部署模板。 图9：快速完成模型设计看看上面的图就知道 了，不到1分钟，整个部署模型就设计完成了，剩下的就是在里面根据业务需要填写、修改参数和部署了。某子曾经曰过：好的工具不仅要能解决用户真正的困难，而且要易于上手，同时有着强大底蕴、深厚的内涵，AOS就刚好符合这几点：1、解决用户在华为云一站式上云时资源、应用部署麻烦的问题2、丰富样例代码、可视化的设计器，据说AOS秘书MM都可以快速上手部署容器应用3、结合这么多年在电信行业大型系统运维过程中踩过的坑，自主研发的编排引擎，和基于tosaca标准规范的模板设计语法，在简单的界面下，深藏玄机，让深度用户可以玩出更多花样，定制出适合自己的场景如果您是研发人员，在为一遍一遍重复搭建开发、测试、QA、类生产等环境感到无聊如果您是运维人员，在为运维过程中复杂的资源管理、监控而烦恼如果您是创业公司，在为如何开启云上事业的第一步而发愁如果您是准备搭上云高速列车的企业，在为如何把企业业务搬迁上云而苦恼速来体验AOS吧!会给您开启一个全新的云世界。https://www.huaweicloud.com/product/aos.html?fromblog?fromblog

记得刚工作那会做了几个网站类项目，每次临近项目上线，都要拉到宾馆封闭开发，搬上几台小机，搭建开发、测试、类生产环境用，因为环境太复杂，每次都是PL们亲力亲为，生怕有一个环节出错就前功尽弃。开局就更是个体力活，扛机柜、搬服务器、架路由器、有些时候网线都要现做。现在想想也不知道是因为公司小，还是当时的IT界就这样，研发和服务其实没分得那么清楚。后来陆续换了一些公司和项目，肩挑手扛的开局慢慢的也有专门的服务团队来做，也就不再是当年研发一家亲的状态了。服务团队会要求我们的软件能快速批量部署，“部署、配置要能通过界面操作”、“要能静默安装”、“安装过程不需要人工干预”、“最好是预安装，机器上电就能用”。在那个年代的IT服务团队已经开始关注自动化、提升效率了。进入云计算1.0时代后，再也不用肩挑手扛的去搭建基础设施，只管从云上申请资源就好了。各云厂商为了吸引客户，也把原来线下平台软件搬上云，丰富这个池子里的资源，以满足用户日趋复杂的业务场景：WEB容器、云数据库、分布式缓存、监控、日志、审计等云上的资源越来越丰富。 在这些新服务的诱惑下，各种C什么O们也不再痴情于自研平台软件，而是直接使用云上服务，而对服务人员来说，运维的难度也就越来越大了，于是服务人员摇身一变开始转攻编程，写出行云流水般的脚本，让部署与日常的运维工作开始变得有序，可能还充满乐趣，这就是自动化的魔力，让我们解放双手的同时，还能取得精神上的满足。既然自动化如此神奇，各大厂商、组织也拿出浑身解数来迎合市场的需求，heat，kubernets，puppet，Chef，Ansible一大堆产品应运而生，各云服务也争相把API开放出来以便满足自动化的要求。如何让用户更方便的对资源、应用、中间件进行管理呢？前方高能。国内大厂推出了解决方案——华为云应用编排服务AOS（Application Orchestration Service）。它可对云上的应用、云中间件、传统的和容器化的计算、存储、网络资源进行统一的部署管理，并通过编排引擎，让用户可自行定义资源、应用间的依赖关系、引用关系等，实现一站式云资源开通和云应用的部署。AOS以华为云上的云服务为基本单位，对每个云服务对象定义了常用的输入、输出与周边依赖，使得用户很容易通过AOS的图形化设计器，将这些元素像画电路图一样，并联或串联起来，并基于设计的图形，一键“点亮资源”（申请资源，并使资源处于可用状态），真正做到 “让用户像用电一样享受云计算”。 图1：这么漂亮的图形化工具，你猜不同颜色的线代表什么意思？下面以典型的电商建站场景为例，看看AOS到底能帮助我们提升多少效率：在没有AOS编排工具前，我们至少需要进行10步操作才能完成，而且每种资源的开通申请，都要到各云服务的页面进行操作，整个过程是相当繁琐的：1、进入网络服务，申请VPC、Subnet2、进入网络服务的安全组页面，创建安全组3、进入弹性云主机服务，创建云主机并绑定EIP4、进入弹性负载均衡，创建ELB，并把云主机添加到ELB的监听范围内5、进入antiddos服务，给ELB的EIP开通antiddos服务，防止DDOS攻击6、进入RDS服务，创建RDS云数据库实例7、进入DCS服务，创建DCS分布式缓存的实例(上面这些还只是最基本的，有可能还需要开通云审计、云日志、云监控、CDN、共享存储等多个服务，来支撑业务系统的运行)8、手动把上面所有资源的信息纪录下来，以备安装应用时配置使用9、上传必须的软件包10、远程登陆到云主机进行安装、配置（看着简单的“安装配置”四个字，其中的辛酸又有多少人知道呢） 使用AOS自动化编排后，可把上面的步骤进行精简，当然要获取极致的自动化部署体验，个人推荐结合CCE（云容器引擎）服务一起使用，双剑合璧，整个过程会让人感受到前所未有的爽快：上面流程的1-7步，我们可以通过AOS模板一步完成，不再需要挨个云服务云申请资源。AOS汇聚了华为云上主流服务的创建、删除、修改API，用户无需再感知云服务的API，只需要按AOS提供的规范定义资源模型和模型间的关系，剩下漫长的开通资源的过程就交给AOS了。直接选取一个自己需要的容器集群进行部署 图2： 涵盖网络、虚机、容器、应用、中间件的样例模板，继续更新中… 图3：选择创建CCE容器集群 图4：创建集群常用的参数都已经自动填充，太贴心了 第8-10步，同样也是通过AOS样例模板一步搞定，我直接选取Magento的电商应用部署，当然如果用户部署的不是Magento的应用，需要手动修改一下模板。图5：选择容器应用的样例模板 图6：可直接进入设计器修改生成自已需要的模板 图7：也可直接进行部署 图8：应用各组件的部署进度、状态一目了然（PS: 示例模板应该是为了展示的便利和学习的方便，把整个场景分别放在了资源和应用两个样例里，真正使用的时候，可以把这两个模板拷到一个文件中，那么整个从底层资源到中间件，再到上层应用的部署，一个部署动作就能搞定）就是这么简单，一个CCE集群和一个基于容器运行的电商应用就出现在眼前了。至于门槛，主要是一些基础的行业知识，比如：· 需要了解yaml（一种比json更简洁的描述语言），写出来的模板不能有基本的语法错误，就像写json时大括号总得写对位置吧· 需要对所使用的云服务、对AOS封装的资源模型有一定的了解，比如创建VPC，你得知道什么是CIDR，创建安全组，你得知道是给TCP是UDP协议做规则，创建RDS您得知道HA与单机的区别吧。· 要清楚业务部署时的依赖关系和先后顺序，比如，要先把云主机创建好，然后开始部署应用AOS想尽办法降低门槛，除了提供上面所说的覆盖各种场景的样例模板外，还为提供了可视化的模型设计器，就好比编程时有了可以直接copy的代码sample，还得有个好用的IDE，这样会大大简化模板的开发，0基础也能快速开发、部署模板。 图9：快速完成模型设计看看上面的图就知道 了，不到1分钟，整个部署模型就设计完成了，剩下的就是在里面根据业务需要填写、修改参数和部署了。某子曾经曰过：好的工具不仅要能解决用户真正的困难，而且要易于上手，同时有着强大底蕴、深厚的内涵，AOS就刚好符合这几点：1、解决用户在华为云一站式上云时资源、应用部署麻烦的问题2、丰富样例代码、可视化的设计器，据说AOS秘书MM都可以快速上手部署容器应用3、结合这么多年在电信行业大型系统运维过程中踩过的坑，自主研发的编排引擎，和基于tosaca标准规范的模板设计语法，在简单的界面下，深藏玄机，让深度用户可以玩出更多花样，定制出适合自己的场景如果您是研发人员，在为一遍一遍重复搭建开发、测试、QA、类生产等环境感到无聊如果您是运维人员，在为运维过程中复杂的资源管理、监控而烦恼如果您是创业公司，在为如何开启云上事业的第一步而发愁如果您是准备搭上云高速列车的企业，在为如何把企业业务搬迁上云而苦恼速来体验AOS吧!会给您开启一个全新的云世界。https://www.huaweicloud.com/product/aos.html?fromblog?fromblog

记得刚工作那会做了几个网站类项目，每次临近项目上线，都要拉到宾馆封闭开发，搬上几台小机，搭建开发、测试、类生产环境用，因为环境太复杂，每次都是PL们亲力亲为，生怕有一个环节出错就前功尽弃。开局就更是个体力活，扛机柜、搬服务器、架路由器、有些时候网线都要现做。现在想想也不知道是因为公司小，还是当时的IT界就这样，研发和服务其实没分得那么清楚。后来陆续换了一些公司和项目，肩挑手扛的开局慢慢的也有专门的服务团队来做，也就不再是当年研发一家亲的状态了。服务团队会要求我们的软件能快速批量部署，“部署、配置要能通过界面操作”、“要能静默安装”、“安装过程不需要人工干预”、“最好是预安装，机器上电就能用”。在那个年代的IT服务团队已经开始关注自动化、提升效率了。进入云计算1.0时代后，再也不用肩挑手扛的去搭建基础设施，只管从云上申请资源就好了。各云厂商为了吸引客户，也把原来线下平台软件搬上云，丰富这个池子里的资源，以满足用户日趋复杂的业务场景：WEB容器、云数据库、分布式缓存、监控、日志、审计等云上的资源越来越丰富。 在这些新服务的诱惑下，各种C什么O们也不再痴情于自研平台软件，而是直接使用云上服务，而对服务人员来说，运维的难度也就越来越大了，于是服务人员摇身一变开始转攻编程，写出行云流水般的脚本，让部署与日常的运维工作开始变得有序，可能还充满乐趣，这就是自动化的魔力，让我们解放双手的同时，还能取得精神上的满足。既然自动化如此神奇，各大厂商、组织也拿出浑身解数来迎合市场的需求，heat，kubernets，puppet，Chef，Ansible一大堆产品应运而生，各云服务也争相把API开放出来以便满足自动化的要求。如何让用户更方便的对资源、应用、中间件进行管理呢？前方高能。国内大厂推出了解决方案——华为云应用编排服务AOS（Application Orchestration Service）。它可对云上的应用、云中间件、传统的和容器化的计算、存储、网络资源进行统一的部署管理，并通过编排引擎，让用户可自行定义资源、应用间的依赖关系、引用关系等，实现一站式云资源开通和云应用的部署。AOS以华为云上的云服务为基本单位，对每个云服务对象定义了常用的输入、输出与周边依赖，使得用户很容易通过AOS的图形化设计器，将这些元素像画电路图一样，并联或串联起来，并基于设计的图形，一键“点亮资源”（申请资源，并使资源处于可用状态），真正做到 “让用户像用电一样享受云计算”。 图1：这么漂亮的图形化工具，你猜不同颜色的线代表什么意思？下面以典型的电商建站场景为例，看看AOS到底能帮助我们提升多少效率：在没有AOS编排工具前，我们至少需要进行10步操作才能完成，而且每种资源的开通申请，都要到各云服务的页面进行操作，整个过程是相当繁琐的：1、进入网络服务，申请VPC、Subnet2、进入网络服务的安全组页面，创建安全组3、进入弹性云主机服务，创建云主机并绑定EIP4、进入弹性负载均衡，创建ELB，并把云主机添加到ELB的监听范围内5、进入antiddos服务，给ELB的EIP开通antiddos服务，防止DDOS攻击6、进入RDS服务，创建RDS云数据库实例7、进入DCS服务，创建DCS分布式缓存的实例(上面这些还只是最基本的，有可能还需要开通云审计、云日志、云监控、CDN、共享存储等多个服务，来支撑业务系统的运行)8、手动把上面所有资源的信息纪录下来，以备安装应用时配置使用9、上传必须的软件包10、远程登陆到云主机进行安装、配置（看着简单的“安装配置”四个字，其中的辛酸又有多少人知道呢） 使用AOS自动化编排后，可把上面的步骤进行精简，当然要获取极致的自动化部署体验，个人推荐结合CCE（云容器引擎）服务一起使用，双剑合璧，整个过程会让人感受到前所未有的爽快：上面流程的1-7步，我们可以通过AOS模板一步完成，不再需要挨个云服务云申请资源。AOS汇聚了华为云上主流服务的创建、删除、修改API，用户无需再感知云服务的API，只需要按AOS提供的规范定义资源模型和模型间的关系，剩下漫长的开通资源的过程就交给AOS了。直接选取一个自己需要的容器集群进行部署 图2： 涵盖网络、虚机、容器、应用、中间件的样例模板，继续更新中… 图3：选择创建CCE容器集群 图4：创建集群常用的参数都已经自动填充，太贴心了 第8-10步，同样也是通过AOS样例模板一步搞定，我直接选取Magento的电商应用部署，当然如果用户部署的不是Magento的应用，需要手动修改一下模板。图5：选择容器应用的样例模板 图6：可直接进入设计器修改生成自已需要的模板 图7：也可直接进行部署 图8：应用各组件的部署进度、状态一目了然（PS: 示例模板应该是为了展示的便利和学习的方便，把整个场景分别放在了资源和应用两个样例里，真正使用的时候，可以把这两个模板拷到一个文件中，那么整个从底层资源到中间件，再到上层应用的部署，一个部署动作就能搞定）就是这么简单，一个CCE集群和一个基于容器运行的电商应用就出现在眼前了。至于门槛，主要是一些基础的行业知识，比如：· 需要了解yaml（一种比json更简洁的描述语言），写出来的模板不能有基本的语法错误，就像写json时大括号总得写对位置吧· 需要对所使用的云服务、对AOS封装的资源模型有一定的了解，比如创建VPC，你得知道什么是CIDR，创建安全组，你得知道是给TCP是UDP协议做规则，创建RDS您得知道HA与单机的区别吧。· 要清楚业务部署时的依赖关系和先后顺序，比如，要先把云主机创建好，然后开始部署应用AOS想尽办法降低门槛，除了提供上面所说的覆盖各种场景的样例模板外，还为提供了可视化的模型设计器，就好比编程时有了可以直接copy的代码sample，还得有个好用的IDE，这样会大大简化模板的开发，0基础也能快速开发、部署模板。 图9：快速完成模型设计看看上面的图就知道 了，不到1分钟，整个部署模型就设计完成了，剩下的就是在里面根据业务需要填写、修改参数和部署了。某子曾经曰过：好的工具不仅要能解决用户真正的困难，而且要易于上手，同时有着强大底蕴、深厚的内涵，AOS就刚好符合这几点：1、解决用户在华为云一站式上云时资源、应用部署麻烦的问题2、丰富样例代码、可视化的设计器，据说AOS秘书MM都可以快速上手部署容器应用3、结合这么多年在电信行业大型系统运维过程中踩过的坑，自主研发的编排引擎，和基于tosaca标准规范的模板设计语法，在简单的界面下，深藏玄机，让深度用户可以玩出更多花样，定制出适合自己的场景如果您是研发人员，在为一遍一遍重复搭建开发、测试、QA、类生产等环境感到无聊如果您是运维人员，在为运维过程中复杂的资源管理、监控而烦恼如果您是创业公司，在为如何开启云上事业的第一步而发愁如果您是准备搭上云高速列车的企业，在为如何把企业业务搬迁上云而苦恼速来体验AOS吧!会给您开启一个全新的云世界。https://www.huaweicloud.com/product/aos.html?fromblog?fromblog

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-21 11:04 编辑司马懿问诸葛亮，依依东望你望的究竟是什么？原来望的就是——华为云 容器训练营。云容器引擎CCE自诞生以来就在使用说明、用户体验上狠下功夫，帮助中心、视频教程、云图说从未间断。然而所谓百闻不如一见，看教程哪有实践操作来得印象深刻。 4月23日，容器训练营正式上线，自己动手的机会来了！训练营提供初级、进阶案例，从创建集群到创建应用一应俱全，让想要体验容器的你快速玩转CCE。 看到这里，有些看过CCE教程的老朋友脑海中可能会闪过一条“温馨”提示： 14268 对，即便CCE是免费的，在使用过程中也会消耗基础设施费用。这条提示可以说是很贴心了，连充值按钮在哪儿都写得清清楚楚，看起来像诱惑程序猿的下班铃。 但是，今天的容器训练营不一样。 14267 容器训练营 完 全 免 费，我们的口号是“体验CCE，0元创集群”！ 无论新老用户，只要是首次使用云容器引擎-训练营，都能领取150代金券，人人可享。 代金券使用无门槛，无需充值即可在训练营中0门槛体验CCE的高效快捷，亲身感受华为云容器技术的内在功力。 14269下面开始体验教程： 首先，您需要登录华为云控制台，并单击体验按钮，果断领取150元代金券，否则系统将判断您为土豪哦。 请戳链接https://console.huaweicloud.com/cce2.0/?region=cn-north-1#/app/guidance/list ，开始愉快创集群吧

本帖最后由 橘色祥云楼楼主 于 2018-4-20 14:52 编辑本文作者：乔雷 原华为PaaS架构师/系统和软件工程师，现Cloud BU中国业务技术支持部解决方案架构师 基于华为云的一个典型的持续部署方案：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker) [*]1. 关于持续集成（CI）和持续部署（CD） [*]2. 一个华为云上的持续部署方案 [*]3. 部署截图 摘要：华为云迄今为止已经有14大类超过100种服务了，可以做很多有用和好玩的方案。本文以一个实际的案例，讲述如何使用华为云上的相关服务(主要是FuctionStage和CCE)完成自动化持续部署（CD，Continuous Deployment)；并且通过Monucular手动部署Helm Charts打包的Kubernetes应用。这充分说明了华为云云容器引擎CCE支持和兼容开源生态Kubernetes以及在DevOps的强大能力，以及华为云支持业界主流自动化部署工具的能力。 1. 关于持续集成（CI）和持续部署（CD）在软件开发和运维领域，我们经常会听到很多概念，比如DevOps，持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)等等。这些新的概念、方法论和工具的出现，主要是为了应对目前业务的挑战。主要是要求业务推出和运维即“快”又“稳”： [*]快：比竞争对手更快的创新、试验和部署业务的能力。快速推出业务、快速获取反馈、快速迭代、快速试错。 [*]稳：快速、频繁地特性发布，同时保证业务和系统的稳定性、可用性和持久性。 下面我们稍微解释一下持续集成（CI，Continuous Integration)，持续交付（CD，Continuous Delivery），持续部署（CD，Continuous Deployment)的概念，可以去参考：持续集成是什么？ [*]持续集成（CI，Continuous Integration)：持续集成指的是，频繁地（一天多次）将代码集成到主干。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。 [*]持续交付（CD，Continuous Delivery）：持续交付指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。 [*]持续部署（CD，Continuous Deployment)：持续部署是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 在本文的场景中，主要讲述的是基于华为云的持续部署（CD，Continuous Deployment)。2. 一个华为云上的持续部署方案前期在支撑某客户在华为云上的概念验证（PoC，Proof of Concept）中，有一个很重要的测试场景：自动化CI/CD。具体场景是：客户在私有云中完成持续集成（CI），CI采用自建的工具链；生成结果自动在华为云上完成持续部署（CD），部署在Docker容器中。客户采用Helm charts脚本部署容器应用，因此在客户的CCE（Cloud Container Engine）容器集群所在的VPC中，我们部署了一台服务器安装了Helm client，通过Helm client连接CCE集群的Kubernetes Master完成Docker容器应用部署。客户部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。我们采用了：FunctionStage(Serverless)+(Monocular+)Helm Chart + CCE(Kubernetes+Docker)的方案完成持续部署。演示效果良好。具体如下图所示：14221描述如下： [*]客户在私有云中完成持续集成（CI），CI采用自建的工具链。CI的结果是： [*]应用容器镜像上传到华为云容器镜像仓库（SWR, SoftWare Repository for Container） [*]应用部署脚本（例如Helm Chart.yaml, values.yaml）等以约定的打包方式，上传到华为云对象存储服务（OBS, Object Storage Service）的指定桶（Bucket）的相应目录下 [*]因为华为云的FunctionStage(Serverless）和OBS有集成，事先在FunctionStage中配置触发器（Trigger），当指定桶（Bucket）的相应应用目录下有文件更新时（PUT/POST操作，即用户上传了应用部署脚本），自动触发一个Python程序的执行。 [*]这个Python程序会ssh到Helm client，执行一个自动化部署的脚本。此自动化部署脚本会执行资源清理、helm install等动作完成容器应用的部署。 [*]部署的容器应用中，其中有一个很重要的容器应用是一个job类应用，它的主要工作是：使用一些自动化部署工具完成应用所需资源的创建，应用环境的初始化等等。完成之后即停止。 [*]最后的结果是：应用通过helm client部署在CCE容器集群中，该创建的资源（例如RDS-MySQL）成功创建并初始化，资源和应用运行正常。 [*]当然，我们也安装了一个Monocular(Monocular is a web-based UI for managing Kubernetes applications packaged as Helm Charts)，允许用户手动部署Helm Charts打包的Kubernetes应用。 3. 部署截图一些部署的截图如下。请注意：这个截图是我手动部署的截图，跟自动化部署的截图是类似的，但更能说明部署过程。 [*]通过Helm client部署容器应用到CCE集群 14158 执行kubectl get pods可以看到应用pod(容器)处于Running状态。 [*]部署过程中通过自动化部署工具创建和初始化的华为云RDS-MySQL资源 14159

本帖最后由 大脸猫爱吃鱼 于 2018-4-12 20:37 编辑作者 王齐林 发布于 2018年1月25日 转自InfoQ 近日，ServiceComb开源了该项目旗下的Go语言微服务框架ServiceComb Go-chassis(以下简称Go-chassis)。作为ServiceComb生态中的重要一环，Go-chassis将和已经开源的Apache ServiceComb(incubating) Java-chassis一道，为用户带来良好的框架级多语言微服务编程体验。同时，ServiceComb Go-chassis未来也会和ServiceComb Java-chassis一样，捐献到Apache基金会中。什么是chassis?Chassis，直译成中文是底盘的意思，它是一种微服务模式，由微服务大师Chris Richardson提出。在这种模式中，用户并不需要自己去处理构建微服务过程中外部配置、日志、健康检查、分布式追踪等那些横切关注点（crosscutting concern），而是将他们交给专门的框架来处理。用户可以更聚焦业务逻辑本身，简单、快速的开发微服务。Apache ServiceComb Go-chassis简介Go-chassis是一个用Go语言编写的微服务快速开发框架，采用插件化设计，将各种功能模块定义为接口，实现功能“可插拔”的同时也带来了非常好的扩展性；用户可以定制开发自己的通讯协议、处理链，对接自己的配置中心、服务发现中心等。Go-chassis的模块及工作流程如上图所示，不同协议请求进入到各协议Server，Server将具体的协议请求转换为Invocation统一抽象模型，并传入Handler chain（ 框架内默认内置了大部分微服务治理所需的handler），最终再进入Transport handler，使用具体的协议客户端传输到目标。目前，Go-chassis支持的特性包括但不限于： [*]服务发现（配合ServiceComb现有的ServiceCenter） [*]动态配置管理： [*]负载均衡 [*]流量控制（服务端与客户端） [*]熔断容错 [*]分布式追踪 [*]Metrics [*]日志 [*]路由策略 在通讯协议方面，Go-chassis原生支持REST/Http 和 Highway协议，其中Highway是ServiceComb开发的、基于RPC的高性能通讯协议。使用Go-chassis开发体质指数应用（BMI）下面，我们将以简单的体质指数应用（BMI）为例，说明如何用Go-chassis快速开发微服务。BMI是国际上常用的衡量**胖瘦程度的一个标准，我们开发的BMI应用主要包含两个微服务： [*]体质指数计算器（calculator）：负责处理运算事务。 [*]体质指数界面（web-app）：提供用户界面及网关服务。 两个微服务之间的关系如下图所示，它们之间通过REST方式进行通信。准备工作在开始开发之前，请确保开发环境上已经完成以下配置 [*]安装 git [*]安装 Go 1.8+ [*]安装 docker [*]下载 ServiceComb go-chassis [code]go get https://github.com/ServiceComb/go-chassis[/code] [*]运行 Service Center 在 ServiceComb 微服务框架中，Service Center 提供服务注册及服务发现功能，可直接使用 docker 运行。[code]docker pull servicecomb/service-center docker run -d -p 30100:30100 servicecomb/service-center:latest[/code]体质指数计算器(calculator) 开发体质指数计算器(calculator)提供运算服务，分为具体业务逻辑、服务注册与配置，启动框架三部分： [*]具体业务逻辑 定义服务结构体[code]type CalculateBmi struct { }[/code]编写计算体质指数（BMI）函数，该函数根据公式13847进行实现：[code]func (c *CalculateBmi) BMIIndex(height, weight float64) (float64, error) { if height = 0 || weight = 0 { return 0, fmt.Errorf("Arugments must be above 0") } heightInMeter := height / 100 bmi := weight / (heightInMeter * heightInMeter) return bmi, nil }[/code]​编写handler函数，其中restful.Context必须作为入参传入。restful.Context中包含了对http调用的Request和Response的常用操作，Read开头的为对Request的读取，包括ReadEntity、ReadHeader、ReadPathParameter、ReadBodyParameter、ReadRequest等；而Writer开头的为对Response的写入操作，包括WriteHeader、WriteJson、WriteError等。[code]import ( rf "github.com/ServiceComb/go-chassis/server/restful" ) …… func (c *CalculateBmi) Calculate(b *rf.Context) { …… //定义返回结构体，此处省略 heightStr := b.ReadQueryParameter("height") weightStr := b.ReadQueryParameter("weight") var height, weight, bmi float64 var err error …… //字符串与浮点数类型转换，此处省略 if bmi, err = c.BMIIndex(height, weight); err != nil { errorResponse.Error = err.Error() b.WriteHeaderAndJson(http.StatusBadRequest, errorResponse, "application/json") return } result.Result = bmi result.CallTime = time.Now().String() b.WriteJson(result, "application/json") }[/code]指定对应的URL路由[code]func (c *CalculateBmi) URLPatterns() []rf.Route { return []rf.Route{ {http.MethodGet, "/calculator/bmi", "Calculate"}, } }[/code] [*]服务注册与配置 完成业务逻辑代码的编写之后，需要将业务逻辑注册到Go-chassis框架，注册时可以同时指定微服务的名称、ID等属性。[code]chassis.RegisterSchema("rest",&CalculateBmi{})[/code]除了在代码中指定的部分属性外，更多的属性是通过配置文件来进行配置。配置文件包括chassis.yaml和microservice.yaml，放置于代码目录下的conf文件夹内。其中，chassis.yaml中配置的是微服务的公共属性，如公共的AppId信息，使用的注册中心类型信息、地址信息，服务的协议、监听地址、注册发现地址、传输协议信息等；microservice.yaml配置的是微服务的私有属性，包括服务名、版本等。chassis.yaml[code]APPLICATION_ID: bmi #应用ID cse: service: registry: address: http://127.0.0.1:30100 #注册中心（ServiceCenter）的地址 protocols: rest: listenAddress: 0.0.0.0:8080 #微服务的监听地址[/code]microservice.yaml[code]service_description: name: calculator #微服务名称 version: 0.0.1 #微服务版本号[/code]启动框架和服务[code]import ( "github.com/ServiceComb/go-chassis" "github.com/ServiceComb/go-chassis/core/lager" ) …… if err := chassis.Init(); err != nil { //初始化框架 lager.Logger.Error("init failed", err) return } chassis.Run() //运行微服务[/code]体质指数界面(web-app)开发开发完后端的calculator服务之后，需要开发提供给用户的交互界面，主要分为前端静态界面、请求转发、服务启动入口三个部分。 [*]前端静态界面 前端静态界面使用了Bootstrap开发，并通过golang 官方库中http.ServeFile将前端静态页面展示出来。[code]func BmiPageHandler(w http.ResponseWriter, r *http.Request) { http.ServeFile(w,r,"external/index.html") }[/code]请求转发体质指数界面（web-app）微服务收到前端界面发过来的请求时，通过core.NewRestInvoker()将请求转发到calculator服务。在转发调用的过程中，用户并不需要感知calculator服务具体的地址和端口，服务发现的过程由go-chassis框架自动完成。[code]func BmiRequestHandler(w http.ResponseWriter, r *http.Request) { queries := r.URL.Query() heightStr := queries.Get("height") weightStr := queries.Get("weight") requestURI := fmt.Sprintf("cse://calculator/bmi?height=%s&weight=%s", heightStr, weightStr) restInvoker := core.NewRestInvoker() req, _ := rest.NewRequest("GET", requestURI) resp, _ := restInvoker.ContextDo(context.TODO(), req) w.Header().Set("content-type", "application/json") w.WriteHeader(resp.GetStatusCode()) w.Write(resp.ReadBody()) }[/code] [*]服务配置与启动 体质指数界面（web-app）服务的配置文件同样包括chassis.yaml和microservice.yaml两个yaml文件，具体内容如下：chassis.yaml[code]APPLICATION_ID: bmi #应用ID cse: service: registry: address: http://127.0.0.1:30100 #注册中心（ServiceCenter）的地址[/code]microservice.yaml[code]service_description: name: web-app #微服务名称 version: 0.0.1 #微服务版本号[/code]与calculator服务不同，体质指数界面（web-app）在Go-chassis框架内是一个消费者类型的服务，故只需调用chassis.Init()对Go-chassis框架进行初始化。[code]func main() { http.HandleFunc("/", BmiPageHandler) http.HandleFunc("/calculator/bmi", BmiRequestHandler) if err := chassis.Init(); err != nil { lager.Logger.Error("Init fail", err) return } port := flag.String("port", "8889", "Port web-app will listen") address := flag.String("address", "0.0.0.0", "Address web-app will listen") fullAddress := fmt.Sprintf("%s:%s", *address, *port) http.ListenAndServe(fullAddress, nil) }[/code]界面效果通过上述步骤，体质指数（BMI）应用已经开发完毕，可以通过http://localhost:8889访问该应用，届时将能看到如下界面，并可输入身高和体重信息验证服务是否正常运行。使用Go-chassis进行微服务治理除了基础的业务逻辑开发外，Go-chassis提供了丰富的微服务治理功能。下面将在刚刚开发的体质指数应用（BMI）基础上，介绍如何使用Go-chassis进行微服务治理。负载均衡当对体质指数计算器（calculator）进行水平扩展时，需要将请求均衡地分发到多个体质指数计算器（calculator）上。Go-chassis的负载均衡功能包括负载均衡策略和负载均衡过滤器两种方式。微服务实例在经过过滤器中制定的规则初筛之后，根据策略算法选出一个合适的实例进行下一步处理。Go-chassis内置了RoundRobin，Random，SessionStickiness，WeightedResponse四种策略，其中默认使用的策略为RoundRobin。此外，无论是负载均衡策略还是负载均衡过滤器，开发者都可以根据自己的需求进行定制。 [*]开启 负载均衡功能默认开启，不需要另外配置。若用户希望使用RoundRobin之外的策略，可以在配置文件chassis.yaml中进行指定。[code]cse: loadbalance: # 全局负载均衡配置 strategy: name: Random microserviceA: # 微服务级别的负载均衡配置 strategy: name: SessionStickiness[/code]对体质指数计算器（calculator）进行水平拓展时，用户只需复制原有代码，并在配置文件中修改监听端口，使得新的实例在另一个端口运行即可。 [*]微服务实例的本地缓存 为了便于区分不同的运行实例，在体质指数计算器（calculator）的实现中新增了返回实例ID的代码。[code]import ( "github.com/ServiceComb/go-chassis/core/registry" ) …… items := registry.SelfInstancesCache.Items() for microServiceID, _ := range items { instanceID, exist := registry.SelfInstancesCache.Get(microServiceID) if exist { result.InstanceId = instanceID.([]string)[0] } }[/code]Go-chassis框架初始化时，会将注册中心中的实例缓存到本地，并每30秒同步一次注册中心和本地缓存的数据（可配置）。代码中使用了本地缓存的数据来获取实例ID。 [*]验证 上述操作完成后，在界面上点击Submit 按钮，可以发现实例ID交替变换。流量控制 [*]开启 流量控制机制通过控制数据传输速率来避免微服务过载运行。用户可以进行服务端流量控制，限制接收处理请求的频率，在体质指数计算器（calulator）的chassis.yaml中可进行服务端流量控制的配置：[code]cse: handler: chain: Provider: default: ratelimiter-provider #添加服务段流量控制的handler flowcontrol: Provider: qps: enabled: true # 是否启用流量控制 limit: web-app: 1 # key为指定要限制的微服务调用者名称，此处web-app为调用calculator的微服务的名称；value为每秒允许的请求数。[/code]也可以进行消费端流量控制，限制发往指定微服务的请求的频率。在体质指数界面（web-app）中的chassis.yaml中配置：[code]cse: handler: chain: Consumer: default: ratelimiter-consumer #添加消费者段流量控制的handler flowcontrol: Consumer qps: enabled: true # 是否启用流量控制 limit: calculator: 1 # key为指定要限制的请求发往的微服务的名称；value为每秒允许的请求数[/code]验证访问 http://localhost:8889，在身高和体重的输入框中输入正数，尝试在1秒内多次点击 Submit 按钮。此时，能看到所有的请求将被后台延迟处理，处理的频率为1次/秒。熔断与降级 [*]开启 熔断与降级主要用于解决或缓解服务雪崩的情况，即个别微服务表现异常时，系统能对其进行处理，从而避免资源的耗尽。用户可以在服务端体质指数计算器（calculator）的chassis.yaml 文件中指明使用服务治理的处理链及指定熔断和容错策略：[code]cse: handler: chain: Provider: default: bizkeeper-provider circuitBreaker: Provider: calculator: requestVolumeThreshold: 3 #10s内发生错误的阈值，超出阈值触发熔断 fallback: Provider: enabled: true fallbackpolicy: Provider: policy: returnnull #出错后的处理策略[/code] [*]验证 [*]使服务进入熔断状态。访问 http://localhost:8889，在身高或体重的输入框中输入一个负数，连续点击三次或以上 Submit 按钮，此时在网页下方能看到类似左图的界面。 [*]验证服务处于熔断状态。在身高和体重的输入框中输入正数，再次点击 Submit 按钮，此时看到的界面依然是类似左图的界面。同时在 体质指数计算器(calculator) 后台运行日志中也能看到 circuit open 的日志。 [*]验证服务恢复正常。约5秒后 ，在身高和体重的输入框中输入正数，点击 Submit 按钮，此时界面显示正常。 分布式调用链追踪开启分布式调用链追踪用于有效地监控微服务的网络延时并可视化微服务中的数据流转。启用分布式调用链追踪，需要在体质指数计算器（calculator） 的 chassis.yaml 文件中添加如下配置，指定追踪数据上报的开关以及上报地址、上报类型等。[code]cse: handler: chain: Provider: default: tracing-provider tracing: enabled: true collectorType: zipkin collectorTarget: http://localhost:9411/api/v1/spans[/code]同样的，在体质指数界面（web-app）中的chassis.yaml中进行如下配置：[code]cse: handler: chain: Provider: default: tracing-consumer tracing: enabled: true collectorType: zipkin collectorTarget: http://localhost:9411/api/v1/spans[/code]此外，还需要运行Zipkin 分布式追踪服务，可以采取Docker方式：[code]docker pull openzipkin/zipkin docker run -d -p 9411:9411 openzipkin/zipkin[/code]验证首先访问 http://localhost:8889 ，在身高和体重栏处输入正数，并点击 Submit 按钮。然后访问 http://localhost:9411 ，进入Zipkin查看分布式调用追踪情况，可得下方界面。​Metrics [*]开启 监控数据能直观的显示微服务应用的性能数据，帮助更好的进行微服务治理、制定弹性伸缩策略等。Go-chassis支持输出Prometheus格式的监控数据，提供的数据包括Golang运行时的数据、微服务进程的内存占用、CPU占用情况等。要使用监控功能，需要在体质指数计算器（calculator） 的chassis.yaml 文件中添加下列内容：[code]cse: metrics: apiPath: /metrics enable: true enableGoRuntimeMetrics: true #是否开启go runtime检测 [/code] [*]​​​​验证 首先访问 http://localhost:8889 ，在身高和体重栏处输入正数，并点击 Submit 按钮。然后访问 http://localhost:8080/metrics（其中8080为体质指数计算器（calculator）服务端监听的端口），可以得到下图所示的监控数据：加入ServiceComb社区​ 本文介绍了ServiceComb Go-chassis的基本特性以及如何使用ServiceComb Go-chassis开发体质指数应用（BMI）以及进行微服务治理。整个示例的源代码可以从Github上获取。同时，作为一个新开源的项目，ServiceComb Go-chassis诚挚的欢迎大家一起参与社区讨论，贡献代码，共同努力打造“最好用的Go语言微服务框架”。 [*]ServiceComb Go-chassis github地址：https://github.com/ServiceComb/go-chassis [*]ServiceComb官方网站：http://servicecomb.incubator.apache.org/ [*]ServiceComb邮件列表：[email]dev-subscribe@servicecomb.incubator.apache.org[/email]

作者介绍：田晓亮，8年软件行业经验，曾就职于三星，2012年进入云计算领域，对PaaS，DevOps，APM有深入的研究和实践经验，方案支撑近千台VM中的应用部署监控。 2016年加入华为担任架构师，负责微服务的Go语言开发框架及Service Mesh设计和落地，Go语言微服务框架已被华为5G核心网络采用，Service Mesh服务也已在华为云商用上线。 微服务架构是个难题，但解法有多个微服务是一个很大的概念，从团队组织到最佳实践似乎都有实施微服务的一些指导。我们这里只提构建微服务的架构模式，也就是关乎到你用什么样的方式来构建你以微服务架构来组织的应用系统。近些年随着微服务的火热，越来越多的团队开始进行实践，将微服务纷纷落地，也许你是从0开始，一步步地完成了单体应用向微服务的改造，让我们来看看，你解决了多少问题。 13830图1 微服务架构需要解决的问题 微服务将原本内存中函数的调用转换为网络中的调用后，就牵扯到这些问题，而任何一个分支展开，都会涉及一系列的问题。业务开发者也许真的有精力去学习架构相关的复杂问题，然而对于公司来说，真正有价值的是业务本身，让业务开发者解决这些问题需要花费浪费大量的时间精力，导致业务上线受到影响。那我们来看看是否有便捷的方式来解决业务开发者的痛点。Chassis模式 一句话来概括：一种语言开发框架来作为微服务开发的底座，封装掉复杂性，帮助你解决跨网络带来的问题，让用户聚焦在上层业务逻辑的开发。通常情况下会实现以下功能： [*]日志、Metrics、分布式追踪数据上报 [*]健康检查 [*]对接统一的配置中心实现动态配置 [*]对接注册中心 [*]实现负载均衡、熔断降级、容错、限流等保证高可靠运行的功能 现在我们来看看业界有哪些可用的Chassis框架 [*]Spring Cloud [*]ServiceComb [*]Dubbo [*]Go-Micro [*]Go-Kit 先不细去纠结微服务的严格定义，也先暂且搁置诸如“某些老旧框架是否是真的微服务框架”这类争议，从实现方式来看，上述服务化框架都是将分布式系统开发的复杂性进行了一定程度的封装然后提供了简便的开发接口供使用者调用。但是，用这种方式构建微服务还有一些问题： [*]多语言SDK支持：微服务提倡不同组件使用最适合它的语言开发，但是这需要每种语言都有开发框架，不断实现相同的功能。上面可以看到只有go语言和Java语言出现了微服务开发框架，其他语言呢？ [*]不论代码侵入程度，都需要开发者思考如何与SDK结合，并从代码层面做出改变，对于大部分开发者来说都是一个高曲线的学习过程。 [*]绑定了特定技术栈，一旦想抽身就需要一定程度上的代码改造。 [*]老旧单体应用由于无人维护，耦合程度高等问题无法进行改造，在进行微服务拆分的过程中重用遗留代码变得无比困难。而且微服务的拆分难以分步进行，需要一个相对较长的周期将系统整体拆分后才能上线。 我们知道技术演进来自于在实践中不断地将功能抽象，解耦，封装，服务化。 [*]云计算技术出现前是数据中心虚拟化，不断地实践使技术发展形成理论和新的实践。IaaS是一种封装，如今开发者与大部分技术团队不需要再学习虚拟化等技术以及如何维护数据中心。 [*]没有TCP/IP的时代，开发人员需要自己考虑网络间数据包的传输，以及网络传输代码与业务代码完全耦合的问题，如今，开发者已经不需要关心，操作系统和开发语言已经封装好网络传输过程。 是否也可以把语言框架提供的能力抽象，成为服务？ 在引入后面内容前，我先介绍下SideCar模式SideCar模式 [*]在近些年受到Kubernetes对容器调度方式的启示而日渐受到关注的一种功能部署模式，也是一种微服务的设计模式。 [*]主要利用了一个Pod中的容器可以共享存储与网络的能力，或者说在一个Host中，这个模式也同样适用。 [*]一般分为应用容器和工具容器，工具容器可以重用。 一个典型的场景如下: 13831图2 SideCar典型场景 应用容器与日志同步工具在同一个Pod下，共享存储卷，应用程序生成的日志文件会由日志同步工具收集并发送到类似kafka，elasticsearch这样服务中。在这样的架构下我们获得了什么呢？ [*]以容器作为基础打包单元，那么就可以分给不同的团队进行开发测试 [*]Sidecar容器可重用，可以与不同的容器结合 [*]以容器作为错误边界，使服务能够独立开发和测试，比如应用服务在没有日志保存功能的情况下也可以独立运行 [*]独立回滚与更新（但需要考虑复杂的版本组合，建议使用语义版本管理对版本进行控制） 在这个模式的基础之下，我们引入了Service mesh。Service Mesh 新瓶中的那一杯老酒什么是Service Mesh Service mesh最早是由Linkerd给出的定义，我们来看看英文版:[indent]A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled by an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.[/indent]大致的意思如下： [*]一种基础设施层服务，服务间的通信通过service mesh进行 [*]可靠地传输复杂拓扑中服务的请求，将它们变成现代的云原生服务 [*]一种网络代理的实现，通常与业务服务部署在一起，业务服务不感知 [*]一种网络模型，在TCP/IP之上的抽象层，TCP/IP负责将字节码可靠地在网络节点间传递，Service mesh则复杂将服务间的协议请求可靠地在服务间进行传输。它们不关心传输的内容 [*]TCP/IP仅仅负责传输，但Service mesh可对运行时进行控制，使服务变得可监控，可管理。 为什么使用Service Mesh [*]无需考虑每种语言都要解决的问题 [*]对业务代码0侵入，开发者无需关心分布式架构带来的复杂性以及引入的技术问题 [*]对于不适合改造的老旧单体应用，提供了一种接入分布式环境的方式 [*]微服务化的进程通常不是一蹴而就的，很多应用选择了演进的方式，就是将单体应用一部分一部分地进行拆分。而在这个过程中，使用Service Mesh就可以很好地保证未拆分的应用与已经拆分出来的微服务之间的互通和统一治理 [*]开发出的应用既是云原生的又具有云独立性，不将业务代码与任何框架，平台或者服务绑定 依然没有银弹，我们来看看Service mesh解决不了的问题 [*]无分布式事务方案 [*]Service Mesh组件代理请求转发，会在一定程度上降低系统通信性能 [*]没有Event Driven的框架 [*]侵入式框架以源码和业务代码结合，有较强定制和扩展能力，Service mesh相对不易定制扩展 [*]在运行时，依赖单独的Service Mesh代理，多了一个故障点。整个系统的运行和运维也强依赖于Service Mesh组件的能力 Service Mesh的实践历程和设计思路Service Mesh在华为公司内部的发展历程 第一代： 基于NGINX的微服务代理该平台是华为公司内部使用的微服务开发部署运行平台，开发于2013年，用于公司内部某电信业务。在这个业务系统中有大概400多个左右的微服务，实例数量根据局点大小不一样，一个典型的部署为800多个左右实例的规模。整体架构如下：13832图3基于NGINX的微服务代理的平台整体架构 其中的Internal Router组件用来给开发者解决分布式架构中的可靠传输问题： [*]使用高性能nginx及其相应的lua扩展作为Internal Router，将Http服务接入 [*]使用RouteAgent负责注册/注销实例，更新IR的实例信息 [*]使用zookeeper作为注册中心 [*]以Per-Host的方式部署在微服务所运行的环境中 用这种方式构建的微服务环境已经在超过200个局点的生产环境下得到使用，整体运行情况良好。但是随着时间的推移，当业务对敏捷的要求越来越大，而且容器的使用也越来越广泛，这种方式带来了一些问题： [*]使用lua脚本扩展注册发现，负载均衡，熔断，降级，容错，限流，但lua的扩展性有一定的局限 [*]用RouteAgent负责服务的注册以及每个NGINX上服务实例路由的刷新，RA需清楚地感知本节点上的微服务都有哪些，但是使用Kubernetes做容器调度后微服务和实例的分布信息在K8S里面集中记录 [*]容器的IP更多，变化更频繁，使用RouteAgent刷新NGINX路由的方式会导致NGINX服务受到影响，频繁的路由刷新导致业务运行收到影响 [*]当IR服务失败后，整个Host中的服务都会丢失，无法与外界建立联系 为了解决这些问题，出现了第二代的解决方案： HSA Sidecar13833图4 HSA Sidecar设计 HSA是华为内部的一套微服务开发框架，它提供了注册中心，配置中心，java开发框架，以及SideCar等组件 [*]基于Java 微服务框架开发,非侵入式通信方式，支持RPC与Http，提供SOAP协议转换，但会导致性能下降 [*]与微服务部署在一个Pod中即Sidecar模式 [*]作为代理服务，使微服务自动获得注册发现，负载均衡，熔断，降级，容错限流等功能 [*]占用资源很高，一个应用实例一个Sidecar实例的部署方式，会占用过高资源 虽然第一代的问题解决了，但是第二代的Sidecar在性能和资源占用上有很大的问题，在少量的技术项目中试用后，因为资源占用过高的问题无法在大规模环境中推广使用。CSE Mesher介绍 Service Mesh 模式的一种实现。基于自研的Go语言微服务框架（该框架即将开源）开发，使用ServiceComb注册中心（已经开源）与CSE配置中心，以Sidecar的方式部署在微服务所运行的环境中，也可以PerHost模式运行。在用户数据面使用，提供VM部署、公有云部署、容器部署，占用资源小（闲置10多M，并发运行时30多M）。基本能力 注册发现注册中心为插件化模块，目前对接了ServiceComb、Service Center，未来还会有更多的系统对接进来 13834图5 可插件化的注册中心 路由规则管理根据预定义的路由规则对请求进行引流 [*]支持权重引流：比如将5%的流量引到购物车的1.0版本，20%引到2.0版本 [*]可根据服务请求特征进行引流：比如消费者的请求中Header带有的用户名为Json，那么可以引流到某个服务的特定版本中 [*]利用读写锁，路由可在运行时更新，并且不丢失请求 协议转换与不同框架的对接与统一治理使用标准OpenAPI契约，可以实现Dubbo RPC协议与Http协议的互转，用于透明地接入遗留的Dubbo应用并对遗留应用进行统一的服务治理使用负载均衡与重试策略 [*]负载均衡器会调用注册中心插件进行实例查询 [*]在查询中的实例里表中，使用Filter进行过滤 [*]将过滤后的实例传入Strategy中进行实例选择 [*]默认提供RoundRobin Random，会话粘滞策略 [*]具备容错能力且加入Backoff算法，增强网络稳定性 使用熔断降级熔断使用的断路器对一个执行过程进行包装，断路器负责监控维护每个执行过程的状态、结果、错误、超时。当达到一定阀值时就会熔断，并触发降级。以这样的机制来保护服务提供者，不会出现级联的雪崩式错误。使用限流提供了消费者端与提供者端限流用户可以通过配置来限制每秒只允许多少个请求被发出或者接受对接监控Metrics：提供了主动上报到CSE Dashborad的方式。也可与华为公有云APM，Prometeus对接 分布式追踪：对接Zipkin架构设计 整体架构13835图6 CSE Mesher整体架构 Mesher背靠CSE组件，使用微服务引擎中的服务中心与配置中心等服务作为控制面，Mesher与业务代码部署在一起运行在数据面数据面13836图7 CSE Mesher数据面 即Service mesh组件本身，对所有请求进行处理，它有以下功能 [*]发现服务 [*]执行路由策略 [*]负载均衡 [*]拦截所有请求并处理，转发 [*]认证鉴权 [*]生成监控数据 控制面13837图8 CSE Mesher控制面 为管理人员提供统一的管理入口，为所有运行的mesher提供配置下发但不会介入服务请求 [*]注册中心：服务上下线感知 [*]下发配置：使用Web Console对运行时更改，负载均衡，熔断容错，限流等策略 [*]对接监控服务与监控页面 [*]调度引擎：这里并非是微服务引擎提供的组件，是可选组件，这个组件负责拉起服务，维护实例数，在资源池中调度分配实例，这里推荐使用ServiceStage负责实例的生命周期管理 运行场景 不同的部署方式与业务服务部署在一起有3种运行模式1.仅消费者使用Mesher，提供者为使用ServiceComb开发框架的服务或者裸服务，下图为例:ServiceC为裸服务,它既不用mesher也不用SDK，那么起码它需要自己注册到服务中心中，供其它服务发现，否则无法进行访问。13838图9 仅消费者使用Mesher 2.消费者与提供者均使用Mesher13839图10 消费者与提供者均使用Mesher 以这种方式运行的服务可以使用透明TLS传输，并且拥有了服务端限流3.提供者使用Mesher，消费者A使用ServiceComb SDK进行开发可直接发现服务B，但是消费者C作为裸服务需要自己发现服务B 13840图11 仅提供者使用Mesher 运行时请求处理消费者端请求 13841图12 消费端发送请求流程 上图为例：SockShop服务将mesher作为代理并使用地址http://order/list访问订单服务 [*]Destination Resolver 目标微服务名解析，支持插件定制，可根据请求特征决定微服务名是什么 [*]Source Resolver 将IP地址解析为微服务实体信息 [*]路由决策 根据Source和Destination 信息决定最终要访问哪个微服务 [*]处理链 处理链为可随时**或减少的模块，在这里Mesher实现了限流，熔断，降级，负载均衡等功能 [*]传输层 最终请求通过传输层发送到目标微服务实例 提供者端接收请求 13842图13 提供者端接收请求流程 上图为收到远程请求后的处理过程 [*]服务端接到请求，将IP地址解析为微服务信息 [*]进入处理链，这一步并没有负载均衡而是直接使用local selection 进行处理 性能对比 13843图14 Mesher1.0、Istio 0.1.6 (Envoy)、Linkerd1.1.3性能对比 在性能对比后，我聊下自己的看法 [*]Linkerd 作为java实现的service mesh，受到资源占用的拖累，考虑到数据中心成本，不适合作为SideCar和应用部署在一起，相信它的主要场景在于Kubernetes Ingress和Daemonset，并且由于只有数据面，需要和别的生态系统对接获得控制面能力，否则，业务团队又要考虑自己开发控制面。 [*]目前Istio已知问题是每次请求都要调用一次Mixer API来传送metric数据，相信未来版本能够解决，但不能满足我们内部的产品节奏。 [*]作为对比，Mesher通过Channel与Go协程机制主动上报metric数据，以此获得更高的性能，机制如下：模块将数据传送到channel中，协程收到信号并主动上报，在这样的机制下开启监控，性能只有百分之2左右的下降。 13844图15 Metric数据上报机制 一些思考以及未来华为为什么开发了自己的Service Mesh [*]Istio的性能问题没有解决，Envoy每次访问请求Mixer API导致性能下降 [*]Istio强绑定Kubernetes平台（1.7.4+），虽然有着良好的架构，对接不同平台不是问题但需要时间，Mesher贯彻不将开发者绑定到任何框架和平台的理念 [*]从成本角度讲Linkerd并不适合做SideCar部署，JVM资源占用较多 [*]过去在ServiceComb中的积累：Service center，Config center，Go SDK，Governance UX已经提供了大量技术积累，可用于做Mesher的控制面。 [*]既然非侵入式与侵入式都不是银弹，侵入式（ServiceComb Java）与Mesher提供的非侵入式框架的无缝结合，混编就变得有价值了，开发者可以因地制宜，选择适合自己的方案。 Service Mesh是个大舞台 现在已经出现了越来越多的Service mesh实现： [*]数据面：Linkerd，Nginx，Envoy [*]控制面：Istio Linkerd 是在2016年出现的，Envoy在6个月后出现，不过Envoy已经在2015年就商用了。这两个项目也是最有名的Service Mesh。Istio在2017年5月出现，它提供了控制面，并使用Envoy作为数据面的Service Mesh。目前已经开始有些Service Mesh提供者宣布与Istio进行集成，比如Linkerd和Nginx。这意味着控制面与数据面是解耦的，任何的控制面都可以和数据面Service Mesh进行集成。CSE Mesher也会考虑与Istio进行集成，成为除了Envoy之外的另一种数据面选择。实际上在开源项目之外，很多公司内部也早已用类似的方案进行自己系统的构建，各自有各自的特点用来解决自己的实际问题。Istio成为CNCF里面一个被认为是“Kubernetes之后的第二个爆款”是有理由的，它提供了一种从平台的角度解决应用架构的思路，进一步简化了应用的开发。我们也相信在这个大舞台上会有更多的方案出现，而这些方案的出现也会让微服务和Cloud Native应用的构建方式有更多地选择。我们团队也已经基于多年的实践经验将当前的内部Service Mesh方案包含在华为云的“微服务引擎”中，开放给外部用户使用。希望可以作为一种参考，可以给正在选择实施微服务架构方案的读者一些帮助。

本帖最后由 橘色祥云楼楼主 于 2018-4-9 11:02 编辑排行榜链接1.重磅！华为云国内首发Windows容器服务http://forum.huaweicloud.com/viewthreaduni-6883-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-092.三亿用户量的微服务化改造 华为云是如何做到的？http://forum.huaweicloud.com/viewthreaduni-6971-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-093. 3月15日晚20:00点直播预告：使用Apache SkyWalking APM 监控 Apache ServiceCombhttp://forum.huaweicloud.com/viewthreaduni-7097-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-094.华为云正式开放区块链服务！与车车科技发布实践应用方http://forum.huaweicloud.com/viewthreaduni-7558-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-095.【CPTS新手入门】全5期，快速上手全收录！http://forum.huaweicloud.com/viewthreaduni-6829-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-096.华为云的Kubernetes实践之路http://forum.huaweicloud.com/viewthreaduni-7719-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-097.【1V1专家咨询】你来提问题，产品经理来回答！http://forum.huaweicloud.com/viewthreaduni-7146-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-098.携手开源中国，华为云容器镜像服务SWR助力用户打造DevOps流程http://forum.huaweicloud.com/viewthreaduni-6990-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-099.【你问专家答】与技术大咖的亲密交流之旅---#云容器实例#http://forum.huaweicloud.com/viewthreaduni-7211-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0910.华为云应用服务大型互动专场，邀您体验趣玩黑科技！http://forum.huaweicloud.com/viewthreaduni-7265-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0911.Cloud 2.0时代，华为云推出四大云上应用服务http://forum.huaweicloud.com/viewthreaduni-7643-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0912.AOS的基本概念！http://forum.huaweicloud.com/viewthreaduni-7514-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0913.【2月干货阅读排行榜】应用服务论坛2月都爱看什么？http://forum.huaweicloud.com/viewthreaduni-6960-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0914.ServiceComb不能做api gateway，但是却有api gateway的一些功能，功能重合怎么办http://forum.huaweicloud.com/viewthreaduni-7171-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0915.【云图说】应用性能管理采集知多少http://forum.huaweicloud.com/viewthreaduni-6888-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0916.管家婆发布基于华为云Windows容器解决方案http://forum.huaweicloud.com/viewthreaduni-7562-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0917.如何在API网关上调用APIhttp://forum.huaweicloud.com/viewthreaduni-6970-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0918.配置中心的 代码会开源吗http://forum.huaweicloud.com/viewthreaduni-6869-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0919.【求助】 配置中心拉取配置时 http返回401 Unauthorizedhttp://forum.huaweicloud.com/viewthreaduni-6859-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-0920.docker save后在界面上传镜像http://forum.huaweicloud.com/viewthreaduni-6918-filter-author-orderby-dateline-page-1-1.html?newsletter2018-04-09

本帖最后由 橘色祥云楼楼主 于 2018-3-29 11:36 编辑13375 华为与 Kubernetes 的渊源颇深，早在 Kubernetes 刚开源的时候就以社区创始成员及白金会员的身份加入其中。目前拥有 1 个 Steering Committee 席位和 5 个 Maintainer 席位。 华为自身基于 Kubernetes 的实践 加入初期，作为全球最大的电信设备制造商之一，华为内部 IT 运维着遍布全球的八个数据中心，在 100K + VM 中运行 800 多个应用程序，使用虚拟机封装应用程序，但每次启动虚拟机都花费了大量的时间，这给管理及部署基于虚机应用程序的高成本和低效率带来了严峻的挑战。因此华为决定利用 Kubenetes 技术对自身 IT 系统进行容器化改造。 与此同时，华为通过参与和贡献 Kubernetes 项目，为自身带来了在规划、网络、多集群联合、应用支持、安全、可扩展性和政策执行等方面的良好设计、代码和文档管理，以及在服务治理方面的收益。通过自身的容器化改造实践，在受益的同时又将自身遇到的实际问题不断的贡献给社区，与社区成员一同推动 Kubernetes 的发展。 比如，在华为内部 IT 系统的实践历程中，业务的全球化属性给平台带来了混合云、跨地域、多 DC 部署方面的需求，这与社区发展多集群联邦的理念不谋而合。因此，华为在集群联邦项目成立之初就积极参与其中，主导了架构设计以及联邦级别的无状态应用、短任务支持、集群间策略调度、应用跨集群自动伸缩等关键特性开发。目前集群联邦已在社区正式孵化为独立子项目。 另一个例子是早期的 K8S 并不支持亲和反亲和等高级调度策略，使得大型传统应用改造上云十分困难。在华为公司对应用做微服务拆分和容器化改造的过程中，最典型的问题就是拆分后的组件间如何高效地通信。在传统方案中，往往有多个组件的业务进程部署在同个虚机上，组件间交互可以通过进程间通信来实现。应用改造后，组件变成了 k8S 中的 Pod，被相对独立地调度和拉起，通过容器网络互相通信。当一个复杂应用的各个组件十分分散时，网络通信的时延会大幅增加。 一方面，针对这个问题，华为在 k8S 社区的主导实现了节点亲和反亲和调度、应用间亲和反亲和调度、Taints tolerations 等高级调度机制。通过给 Pod 配置高级调度策略干预应用组件的分布，配合容器网络在路由策略上的优化，访问时延问题得到了显著的改善。 另一方面，在集群规模和性能方面，华为也做了很多探索与实践。面对大规模场景下海量 Service 的管理性能问题，华为设计实现并向社区贡献了使用 IPVS 管理 service 路由规则的方案，将 k8S 对 service 的管理规模从上千提升到了数万的级别。 华为云应用服务与 Kubernetes 华为云应用服务产品均围绕着“容器”为中心构建，致力于帮助客户容器化的应用在云上高效地开发、交付与运维，并保障应用运行时的高性能、高可靠、高弹性。目前，华为云应用服务产品以基于 K8S 的华为云容器引擎（CCE）为核心，协同补齐了完整的应用开发、交付与运维流程，为客户提供完整的一站式云上应用生命周期管理方案。 华为云应用服务大体上可以分为三大类： 第一类围绕着 Kubernetes 核心功能，也就是容器编排与调度，与下层的基础设施层包括计算、网络、存储，以及水平的权限控制、网络防护、镜像仓库等服务进行整合形成一个容器化基础设施平台，并向上对接到集群管理、多 DC/AZ、多区域管理实现云上的水平弹性。通常大家所提到的“容器服务”或“容器云”大部分都是指这一类服务。华为云所提供的云容器引擎（CCE）、云容器实例（CCI）归属于此类。两者均基于 Kubernetes 构建，但技术路线偏重点有所区分。 CCE 的服务形态是用户专属的 Kubernetes 集群（Kubernetes as a Service），用户能够控制整个 Kubernetes 集群的资源与应用，并且可以调用完整的 Kubernetes API，以及安装各类 Addon 以及自定义扩展比如调度器、工作负载控制器等；而 CCI 的服务形态是无服务器容器（Serverless Container），用户无需感知 Kubernetes 集群，通常只需要调用 Kubernetes Workload API 进行应用的管理即可，而把资源全部交由华为云进行自动调度与管理。因此，通常 CCE 适合业务半托管的场景，即用户自身有一定运维能力，且业务场景需要用户手动做一些管控比如资源规划、弹性伸缩，甚至自定义一些平台特性以适配业务；相对而言 CCI 适合业务全托管的场景，即用户只需关注以容器形态所交付的应用本身，无需关注资源管控，甚至无需关注 Kubernetes 的相关原理。 第二类服务围绕着 Kubernetes 标准化接口以及结合具体场景的最佳实践来构建完整的应用开发、交付与运维流程，实现云上的应用全生命周期管理。华为云在开发阶段提供微服务开发框架帮助用户在产品开发中落地微服务架构实践，在交付阶段提供“从代码到容器镜像”的自动镜像构建服务，支持一键式部署到 Kubernetes 平台之上，实现持续交付，而最终业务上线运行之后的运维阶段除了基础的容器监控、日志、告警系统之外，同时提供了微服务治理引擎，以及应用性能管理用于故障在线辅助与自动定位。 具体举例而言：[indent] [*]华为云微服务引擎（CSE）提供了具备升降级、容错、熔断等完整服务治理能力的微服务框架，兼容 Spring Cloud、Dubbo 等开源接口，并与 CCE 深度整合，支持 ServiceMesh，未来计划进一步与 CNCF 基金会各微服务相关项目，尤其是 Istio 生态相结合，提供最适合在 K8S 之上运行业务所使用的微服务开发框架 [*]华为云应用编排服务（AOS）提供了以应用为中心的高层编排引擎，能够将 K8S 上运行的各种工作负载、各类资源对象整合管理，并提供了完善的版本与生命周期管理机制，便于客户以更高层的“应用”为对象进行日常交付与运维管理 [*]华为云应用性能管理（APM）提供了丰富的各类运维工具，除了基础的监控、日志与告警，进一步面向故障定位与分析场景提供了应用全局性能拓扑展示与调用链跟踪等高级特性，使得运维人员能够及时了解应用健康状态并进行相关处理。 [/indent] 第三类则是直接在 Kubernetes 之上身体力行地构建一些典型服务化应用，针对某些业务场景提供更易用、更高效的服务，使得客户更聚焦自身业务逻辑。比如：[indent] [*]以分布式数据库（DDM）、分布式缓存（DCS）、分布式消息（DMS）为代表的云化中间件服务，供应用业务逻辑所调用，辅助客户应用的容器化、无状态化、微服务化开发或改造； [*]以 CCE/CCI 为基础设施层所构建的 Serverless Computing（FunctionStage）服务，面向 Event-Driven 的典型业务流场景简化应用代码逻辑，并基于容器热启动、各类主流语言运行时的快速启停优化，实现更高效、更低成本的实时计算； [*]区块链服务 BCS 则提供了主流的 Hyperledger 开源框架，并基于 Kubernetes 的高性能实现 3 分钟一键上链，2000+TPS 的并发区块处理能力，可满足联盟链与私有链的各类业务场景诉求，使客户免运维地使用区块链构建自有业务框架。 未来：紧随社区版本 持续优势创新 纵观华为在 Kubernetes 上的创新可以总结为优势创新、场景创新、技术创新三个层面，优势创新是围绕华为固有的自身强势领域如网络、硬件进行与容器技术的结合运用。场景创新则是聚焦在不同领域的客户需求如游戏、电商、AI 等，基于客户的计算需求进行解决方案的适配。技术创新，以无服务器容器为例，在 Serverless 的云服务趋势下，华为云提供更加便捷，更加全新理念的容器服务方式。目前看来，容器服务并没有统一的服务标准，并没有说哪一种创新可以一招解决所有企业云上容器化的痛点，这需要根据客户的业务场景进行量身匹配，而华为云的全栈容器服务的实践案例也充分说明了这一点。众多不同的容器服务在上线不久已应用在众多不同领域，裸金属容器已成功运用在一部分游戏客户中，帮助其进行测试环境，及高峰时间的流量应对。Windows 容器成功运用在传统 IT 系统的容器化改造，而无服务器容器则可以帮助更多缺乏 Kubernetes 技术投入的公司快速上手享受容器化带来的益处。 这也就是华为云对于 Kubernetes 的一些探索和思考，未来还会有更多基于容器的创新，一切才刚刚开始。 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~作者简介 华为云应用服务技术团队，在容器与微服务领域具备长期的技术与实践积累，以领先的容器与微服务等云原生技术专注解决应用上云前后的技术难题，助力企业应用上云更加简单、运行更高效。~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 活动推荐 随着 AI、Big Data、Cloud 的逐渐成熟，FAAS、CAAS 等技术的兴起，以及被运维业务的多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，AIOps 智能运维、大数据运维、ChatOps、SRE、Chaos Engineering、微服务与容器运维等新技术和方向应运而生，它们一方面把最前沿的技术结合到运维中来，一方面在人员角色、领域范围、文化等方面又有了很多扩展，让传统运维有了翻天覆地的变化。来 QCon 北京 2018 与国内外一线技术专家探讨运维前沿技术趋势，及其最佳实践和落地方略。目前大会 9 折报名中，立减 680 元。有任何问题欢迎咨询票务经理 Hanna，电话：010-84782011，微信：qcon-0410。13376 [/indent]