【.com原稿】2017年12月01-02日，深圳中洲主办的WOTD全球软件开发技术峰会万豪酒店将隆重举行。本次峰会以软件开发为主题，数十位专家嘉宾将带来众多精彩纷呈的技术内容分享环节。届时，熊浦江先生将在“微服务与容器技术”专场与嘉宾分享“云微服务架构运维思考”的主题演讲。熊浦江老师将详细讲解“微服务架构”的特点和发展趋势，结合微信业务在微服务架构上的探索、应用、改进和推广，分析运维如何应对微服务架构中的各种业务问题。微服务架构环境。挑战。”诚邀您莅临大会，与我们一起分享科技带来的快乐。互联网技术日新月异，同时，移动互联网和云时代正在到来，微服务架构应运而生。下图为我国微服务的百度搜索指数：从图中可以看出，微服务从2013年左右开始逐渐受到人们的关注，随着时间的推移搜索的人越来越多，直到断了2016年出炉。微服务架构的快速发展和广泛流行与以下因素密切相关：互联网技术架构的快速演进，尤其是底层硬件和芯片技术的快速发展，以及后端服务器能力的不断增强.在大多数情况下，单个业务很难消耗掉整个服务器的资源或处理能力。移动互联网的融合应用和瘦客户端的兴起，使得云能力和承载能力更加重要。容器技术得到广泛认可和应用，轻量级协议、代码管理、新的集成方法和工具等技术日趋成熟。近两年，微服务这个词逐渐成为一个流行词汇，但它并不是一个新的架构，更不是包治百病的架构。那么，微服务架构相比单体架构有哪些优势呢？这些优势给开发模式和运维带来了哪些痛点？微服务架构的优势和痛点微服务和单点服务有什么区别？打个比方，点菜服务就是把所有东西都放在一个大盒子里，这个大盒子什么都有。微服务更像是汽车箱。每个盒子都包含特定的功能模块和物品，一切都可以灵活拆分。换句话说，在点菜服务中，所有的部分都在一个巨大的包裹中。在微服务架构下，有很多独立存在的小服务，通过API接口连接起来形成一个庞大的系统。与以往的单体应用架构相比，微服务架构具有明显的优势，例如：单个微服务更易于理解，开发和维护方便。应用程序解耦使开发迭代对于整体应用程序交付更加敏捷。技术的选择更加自由，微服务不再需要限制统一的技术实现。微服务独立部署，应用更稳定，扩展更简单快捷。……同时，微服务架构的特点和优势也带来了很多开发模式、运维方面的痛点，比如：微服务众多，容器编排和部署管理会变得异常复杂。业务容量管理难度加大，资源利用效率难以提升。监控粒度变大，关联关系变复杂。微服务故障恢复和调度需要更加细化。...微信中两个典型的微服务案例熊浦江先生表示，微信一直提倡敏捷开发，“大系统，小工作”，这其实就是微服务理念和架构的实现。自2011年微信诞生以来，微服务架构的概念还没有出现。也就是说，微信的微服务架构实现和落地在业界是比较早的。微信中有很多微服务案例。这里主要分享两个典型的服务布局和过载保护案例。服务布局微信服务布局采用多区域自治、园区互备的架构。下面是微信的服务布局示意图：城市之间的数据相对独立。除了少数账户的全球同步外，大部分业务都希望是邮件式的服务，各自运行在自己的环境中，使用类似邮件的通信方式。城市之间的备份使用公网的udp通道。在城市中，采用三园式建筑。每个园区都是一个独立的系统，在接入层、逻辑层、存储层完全独立，可以互为备份。多个园区形成整体服务能力。在园区内，一套由多台机器组成，相互容错，网络和电源也是独立的。这样的服务布局不仅仅是微服务架构，还考虑了容灾能力。过载保护过载保护的微服务架构旨在保证核心服务的可用性。保证核心服务的可用性有三点：应该考虑的是服务要重重分离，即一个服务不能既有重操作也有轻操作。队列控制，需要知道一个请求在队列中停留的平均时间，从而决定是否开始拒绝；结合命令式的方式，因为微服务的调用链和层级可能会增加，可能会有多个后端服务。假设后端有两个服务（A服务和B服务），前端调用需要依赖A服务和B服务的组合结果，那么单个A或者单个B稍微过载就可能导致前端服务不可用，这是非常严重的问题。在这种情况下，需要一个反馈机制。下面是过载保护的微服务架构示意图：如上图所示，整个系统以反馈为主，全程传递拒绝信息。在最右边，有几个典型的服务。当一个CGI调用一个后台服务，再调用另一个后台服务时，系统会在CGI层面传递它的重要性。回到刚才前端调用A和B服务的例子，使用这样的重要性转移可以直接拒绝同一批用户20%的请求，有效解决了单个服务轻微过载的问题。写在***里如果想了解更详细的内容，比如随着业务的发展，微服务架构应该做哪些调整或研发，运维是怎么安排的，在开发过程中遇到了哪些困难过程，以及技术团队如何回应！欢迎各位朋友莅临WOTD峰会现场，聆听熊浦江先生的精彩演讲。使用优惠码【2017WOTDSZ】，跟我一起去WOTD全球软件开发技术峰会吧。20%折扣，仅剩48小时！【原创稿件，合作网站转载请注明原作者及出处为.com】
