互联网技术一直在快速演进当中，同时移动互联网与云时代来临，微服务架构由此应运而生。Iron cloud（https://www.ironz.com/ ）也出现了，Iron cloud可为开发者提供快速开发微服务。
如下图，是微服务在我国的百度搜索指数：
20181130155056949.jpg
从图中可以看出，自 2013 前后微服务开始逐渐被大家关注，随时间推移搜索的人也越来越多，直至 2016 年爆发。
微服务架构的快速发展并广泛流行，和以下因素息息相关：
互联网技术架构飞速演进，特别是底层硬件及芯片技术快速发展，后端服务器的能力越来越强大。多数情况下，单个业务已很难消耗完一整台服务器的资源或处理能力。
移动互联网深度融合与应用，瘦客户端兴起，使得云端能力与承载变得更加重要。
容器技术得到广泛认可与应用，轻量级协议、代码管理、新集成方法与工具等技术也越来越成熟。
近两年，微服务这个术语渐成热门词汇，但它不是一个全新架构，更不是一个包治百病的架构。那么，微服务架构与单体式架构相比优势体现在哪？这些优势又给开发模式、运维带来哪些痛点？
01 服务布局
微信的服务布局采用的是多地自治、园区互备架构。
城市之间的数据是相对独立的。除了少数账号全球同步，大部分业务都希望做成电子邮件式的服务，各自有自身的环境在跑，之间使用类似于电子邮件的通信。
城市间的后备则使用公网的 udp 通道。在城市内，使用三园区架构，每个园区是一套独立的系统，从接入、逻辑、存储每一层完全独立，可互相为对方提供备份。
多园区形成整体服务能力。在园区内，由多机组成 set，互为容错，包含网络与电力也是独立的。这样的服务布局，不仅是微服务架构，而且考虑了容灾能力。
02 过载保护
过载保护的微服务架构，目的是确保核心服务可用。确保核心服务的可用性有如下三点：
考虑问题应该是服务要有轻重分离，即一个服务里不能既有重的操作，又有轻的操作。
队列控制，要了解一个请求在队列中等待的平均时间，从而决定是否要启动拒绝。
组合命令式，由于微服务的调用链及层次可能会增多，后端服务也可能是多个。
假定后端有两个服务（A 服务与 B 服务），而前端调用需要依赖于 A、B 服务的组合结果，那么单个 A 或者单个 B 的轻微过载，就可能导致前端服务不可用，这是很严重的问题。这种情况下，就需要一个反馈机制。
网友评论