带你走进微处理架构的世界

摘要: 微处理架构——处理复琐事物 　　许多公司，好比Amazon、eBay和NetFlix，经过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相链接的微服务。

微服务正在博客、社交媒体讨论组和会议演讲中得到愈来愈多的关注，在Gartner的2014 Hype Cycle上它的排名很是靠前。同时，软件社区中也有很多持怀疑论者，认为微服务不是什么新东西。Naysayers认为这就是SOA架构的从新包装。然 而，尽管存在着不一样的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助。

首先咱们看看为何要使用微服务。

开发单体式应用

假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，通过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图以下：

应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。

尽管也是模块化逻辑，可是最终它仍是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格 式，部署在Tomcat或者Jetty上，而另一些Java应用会被打包成自包含的JAR格式，一样，Rails和Node.js会被打包成层级目录。

这种应用开发风格很常见，由于IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只须要简单运行此应用，用Selenium连接 UI就能够完成端到端测试。单体式应用也易于部署，只须要把打包应用拷贝到服务器端，经过在负载均衡器后端运行多个拷贝就能够轻松实现应用扩展。在早期这 类应用运行的很好。

单体式应用的不足

不幸的是，这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中， 开发团队都会面对新“故事”，而后开发许多新代码。几Year后，这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子，我最近和一个开发者讨论，他正在 写一个工具，用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是不少开发者通过多Year努力开发出来的一个怪物。

一旦你的应用变成一个又大又复杂的怪物，那开发团队确定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以致于任何单个开 发者都不可能搞懂它。所以，修正bug和正确的添加新功能变的很是困难，而且很耗时。另外，团队士气也会走下坡路。若是代码难于理解，就不可能被正确的修 改。最终会走向巨大的、不可理解的泥潭。

单体式应用也会下降开发速度。应用越大，启动时间会越长。好比，最近的一个调查代表，有时候应用的启动时间竟然超过了12分钟。我还据说某些应用须要40分钟启动时间。若是开发者须要常常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。

另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是天天会改变不少次，而这对于单体式应用模式很是困难。另外，这种变化带来的影响并无很好的被理解，因此不得不作不少手工测试。那么接下来，持续部署也会很艰难。

单体式应用在不一样模块发生资源冲突时，扩展将会很是困难。好比，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，因为这些模块部署在一块儿，所以不得不在硬件选择上作一个妥协。

单体式应用另一个问题是可靠性。由于全部模块都运行在一个进程中，任何一个模块中的一个bug，好比内存泄露，将会有可能弄垮整个进程。除此以外，由于全部应用实例都是惟一的，这个bug将会影响到整个应用的可靠性。

最后，单体式应用使得采用新架构和语言很是困难。好比，设想你有两百万行采用XYZ框架写的代码。若是想改为ABC框架，不管是时间仍是成本都是很是昂贵的，即便ABC框架更好。所以，这是一个没法逾越的鸿沟。你不得不在最初选择面前低头。

总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，没法理解的怪物。由于采用过期的，效率低的技术，使得雇佣有潜力的开发者很困难。应用没法扩展，可靠性很低，最终，敏捷性开发和部署变的没法完成。

那么如何应对呢？

微处理架构——处理复琐事物

许多公司，好比Amazon、eBay和NetFlix，经过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相链接的微服务。

一个微服务通常完成某个特定的功能，好比下单管理、客户管理等等。每个微服务都是微型六角形应用，都有本身的业务逻辑和适配器。一些微服务还 会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每个实例多是一个云VM或者是Docker容器。

好比，一个前面描述系统可能的分解以下：

每个应用功能区都使用微服务完成，另外，Web应用会被拆分红一系列简单的Web应用（好比一个对乘客，一个对出租车驾驶员）。这样的拆分对于不一样用户、设备和特殊应用场景部署都更容易。

每个后台服务开放一个REST API，许多服务自己也采用了其它服务提供的API。好比，驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。全部服务都是采用异步的，基于消息的通信。微服务内部机制将会在后续系列中讨论。

一些REST API也对乘客和驾驶员采用的移动应用开放。这些应用并不直接访问后台服务，而是经过API Gateway来传递中间消息。API Gateway负责负载均衡、缓存、访问控制、API 计费监控等等任务，能够经过NGINX方便实现，后续文章将会介绍到API Gateway。

----------------------------------------------------------------------------------------

完整的项目源码来源  欢迎你们一块儿学习研究相关技术，源码获取请加求求:2670716182