微服务生态体系建设之 三个火枪手（1）微服务

在开始本文之前，我先提困扰我们的几个问题

1. 一个系统的建设，从需求开始，到正式发布，通常要等大半年甚至更长的时间，能快点吗？
2. 系统的一个变更，从提出到发布上线，通常也要等一个月的时间,能快点吗？
3. 一个系统重新发布，系统也需要停上一两个小时，甚至更长，能快点吗？或者是否可以不宕机发布？
4. 一个终极问题，据统计，一个项目，从立项到与乙方签订合同，商务流程就要走上半年的时间，能快点吗？

以上这些问题如何解决，彩蛋就在本系列《三个火枪手》中

这张图大家一看就知道，说的是今年1月份一位乘客为了等她老公，死死把住一节高铁车厢的车门，导致高铁无法正常发车的事情。

那这件事对于一个习惯于IT思维的我们来说，会有什么想法呢？

• 当高铁在运行的时候，高铁上任何一个高危故障或者乘客有紧急情况需要下车急救，都有可能导致整个列车停运，影响所有乘客
• 在高铁列车从生产线上下线时，列车上任何一个缺陷，都有可能导致整个列车无法正常交付使用。

以上几点，让你联想到了我们的应用系统了吗？哈哈

那怎么办？如果我们用汽车车队的方法来运送乘客呢？

• 车队可以随时接送乘客，一辆汽车出现故障或者有乘客出现紧急情况，不影响整个车队的其他车辆运送乘客，有故障的车可以很快找到替代汽车继续服务。
• 车队的汽车从生产线上下线时，一辆车无法报交不影响其他车辆投入正常使用。而且每辆车的生产报交周期会大大短于一辆列车的报交周期。

讲到这儿，大家就明白了，高铁模式，就是我们的单体模式，而车队模式，就是我们说的微服务架构模式。

微服务架构模式能解决这两个问题，那么它就没有投入吗？

实际上，由于微服务架构是分布式架构，由此带来了许多问题需要解决。

再回到车队来考虑这个问题，为了协调车队的正常运行，我们需要有一个调度中心来进行调度（微服务的服务网关），调度中心需要有车队所有在用车辆的信息（ 微服务注册中心），对在用和备用的车辆都要进行统一管理（微服务的治理、画像），每辆车都是什么配置，上面有多少乘客，从哪里来，到哪里去（微服务配置中心），哪几辆车是运送同一个旅行团的、这些车必须更紧密地跟踪（调用链追踪），如果一辆车出了故障，或者失联了，我们是一直等它呢，还是果断停止联络、之后再试（微服务的断路器），在运送过程中时时刻刻都要点人头确保人数一致，还是同一旅行团的乘客到了目的地再点人数（最终一致性）……

所以，你看，当采用微服务分布式架构的时候，原先单体模式不用考虑的问题都来了。

怎么来解决这些问题？答案很简单，就是建设微服务框架，把微服务的管理问题交给框架来解决。

如果这个问题解决了，那么为什么要用微服务这个问题的答案也就简单了，那就是一个字“快”，当今世界，唯快不破！

实际上，微服务框架的思想，在实际生活中到处存在。我们知道明朝初期的大航海家郑和，乘风破浪，直达非洲南端好望角，路途遥远而凶险，却平安往返数次，这是怎么做到的呢？据说，郑和的宝船名为“福船”，之所以这么叫，是因为它用了水密隔仓技艺，它把船舱隔成一个个小仓，如果有小仓漏水，可以方便地把它隔开来，水只进这个小仓，不会蔓延到整个船舱，这就是微服务里的熔断隔离技术，确保一个微服务出现问题而不会影响到整个系统的运行。

好了，讲这么多，大家一定想知道微服务长什么样？大家可以参考Chris Richardson 老爷子的微服务系列文章Introduction to Microservices.  后续我们专家会深入介绍微服务及其框架技术相关内容。下图是微服务应用的逻辑架构的长相：

，

而支持微服务应用正常运行的微服务框架的基础组件至少但不止于以下这么多:

接下来，大家就会提这些问题了，微服务为什么这几年才火起来?微服务开发用什么姿势最好？后续我们会逐一介绍。敬请期待吧。

参考文献： Introduction to Microservices

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！