作为一名IT从业者，懈怠是一件奢侈的事情，因为在IT圈，原地踏步就等于退步。
“微服务”这个名词已经广为流传，但是我觉得大部分的人也许同我一样，仅仅只是处于对这个概念的认知上；是的！今天我希望跟大家一起揭开它的神秘面纱:)
本次系列文章主要是记录自己一点一点学习微服务的过程，希望大家能和我一起探讨或者指正不足［抱拳］。
-
我们为什么要使用微服务架构
在我从事架构师的这几年，我带领团队做过很多项目，以小中型为主，很少涉及大型项目，因此我设计的架构往往都是单体式应用，以下架构拓扑图是我最常用的：
对于不同项目性能需求，通过横向扩展服务器数量基本上可以达到。
其实上图的架构就是一个通用典型单体架构，应用核心是业务逻辑，有API网关和Service业务模块构成，前端通过Nginx负载均衡对外提供Web服务或者REST API服务。
尽管也是模块化逻辑，但是最终它还是会被打包成War并部署为单体式应用。通过多个tomcat来横向扩展访问瓶颈，非常简单易用，也基本上解决了我工作中的多数项目问题～
那么问题来了，这种架构到底有什么问题？
- 从开发角度来讲：假如我要修改某一点业务（比如工资结算的一个算法优化），那么我修改完这个class后，需要把这个web工程重新编译并打包；
- 从部署角度来讲：一句代码的修改，需要讲所有的服务器重新替换war后部署一遍；
- 从测试角度来讲：我们不但需要做变更业务的测试，我们还需要做各种回归测试，我们不确定这个方法的改动或者这个变量的改动，会不会对其他方法或者class产生影响，所以我们需要做全面的测试，即使只修改了一句代码。
我相信大多数人可能遇到过这样的问题：我们要接手修改离职的同事写的代码，复杂的业务逻辑，混乱的命名规则看的脑袋疼，有时候为了修改一个bug，我们花了几天的时间才捋顺了逻辑，到了最后可能就修改了一两句代码，这个工作很耗时，情绪也很不好，代码变得越来越难以维护。
另外，在如今互联网的时代，敏捷开发，快速迭代，持续发开已经成为一种常态，然而这些新特性在单体式应用上很难实现；所以如果你要处理相对大型的，复杂的业务，那么从现在开始学习微服务架构吧！
-
什么是微服务架构？
Martin Folwer对微服务架构的定义是：
［微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。］
［敲黑板］在这里有一个很大的概念误区（起码我以前是混淆的）：“微服务”和“微服务”架构，这是两个不同的概念，他们有着本质的区别：“微服务”强调的是服务的大小，它关注的是某一个点，而“微服务架构”是一种架构思想，需要从整体上对软件系统进行考量。我之前曾经看过一段很有名的评论：
［Chris Richardson说：“
微服务”是一个很糟糕的名字，它导致开发人员创建了许多粒度很小的服务，每个服务拥有一个单独的REST端点。不仅如此，这个名字还暗示了微服务在开发者心目中的重要位置。例如，人们会说“我们可以用微服务来解决这个问题”；我也看到了越来越多的“某某微服务框架”，而实际上，这些框架跟微服务架构不一定有太多联系，它们只是简单的Web框架（如：spring-boot）。使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务。］
我将原来的一个很大的复杂war包拆成了一系列的简单的应用，每个应用只关注自己的业务：比如，对于手机用户，对于pc用户不同用户，设备和特殊场景，都分别部署不同的应用服务。
每一个后台服务开放一个REST API，比如API1，API2...n，外界同API不能直接进行交互，需要通过API网关来传递消息。API网关负责负载均衡，缓存，ACL，计费，监控等等。
不同的服务之间，比如API1和API2之间也会有访问与被访问的关系，我们在后续章节再讨论这部分。
-
本章总结
对比我的第一张架构图和第二张架构图，我认为从架构演变来说，有以下几点：
- 图1的所有服务出口单一，图2服务出口有多个，根据设备的不同，需求的不同，可以分离维多个出口；
- 图1的业务是集合的，只能通过复制备份的方式横向扩展，图2业务是非耦合的，尽可能在单一服务中处理单一集中性业务，不掺杂其他无关业务；
- 图1代码修改后，需要把所有服务器重新部署一遍；图2只需要针对性的部署修改的具体服务，其他无关服务不需要变化。
好了，由于篇幅关系，今天我们就讨论到这里，欢迎大家讨论和建议；如果感兴趣的话，请关注后续文章：）
以上。