从零开始学习微服务架构(一)

　　做为一名IT从业者，懈怠是一件奢侈的事情，由于在IT圈，原地踏步就等于退步。

　　“微服务”这个名词已经广为流传，可是我以为大部分的人也许同我同样，仅仅只是处于对这个概念的认知上；是的！今天我但愿跟你们一块儿揭开它的神秘面纱:)

　　本次系列文章主要是记录本身一点一点学习微服务的过程，但愿你们能和我一块儿探讨或者指正不足［抱拳］。

---

 

• 咱们为何要使用微服务架构

　　在我从事架构师的这几年，我带领团队作过不少项目，以小中型为主，不多涉及大型项目，所以我设计的架构每每都是单体式应用，如下架构拓扑图是我最经常使用的： 

　　对于不一样项目性能需求，经过横向扩展服务器数量基本上能够达到。

　　其实上图的架构就是一个通用典型单体架构，应用核心是业务逻辑，有API网关和Service业务模块构成，前端经过Nginx负载均衡对外提供Web服务或者REST API服务。

　　尽管也是模块化逻辑，可是最终它仍是会被打包成War并部署为单体式应用。经过多个tomcat来横向扩展访问瓶颈，很是简单易用，也基本上解决了我工做中的多数项目问题～

　　那么问题来了，这种架构到底有什么问题？

1. 从开发角度来说：假如我要修改某一点业务（好比工资结算的一个算法优化），那么我修改完这个class后，须要把这个web工程从新编译并打包；
2. 从部署角度来说：一句代码的修改，须要讲全部的服务器从新替换war后部署一遍；
3. 从测试角度来说：咱们不但须要作变动业务的测试，咱们还须要作各类回归测试，咱们不肯定这个方法的改动或者这个变量的改动，会不会对其余方法或者class产生影响，因此咱们须要作全面的测试，即便只修改了一句代码。

　　我相信大多数人可能遇到过这样的问题：咱们要接手修改离职的同事写的代码，复杂的业务逻辑，混乱的命名规则看的脑壳疼，有时候为了修改一个bug，咱们花了几天的时间才捋顺了逻辑，到了最后可能就修改了一两句代码，这个工做很耗时，情绪也很很差，代码变得愈来愈难以维护。

　　另外，在现在互联网的时代，敏捷开发，快速迭代，持续发开已经成为一种常态，然而这些新特性在单体式应用上很难实现；因此若是你要处理相对大型的，复杂的业务，那么从如今开始学习微服务架构吧！

---

 

• 什么是微服务架构？

　　Martin Folwer对微服务架构的定义是：

　　［微服务架构是一种架构模式，它提倡将单一应用程序划分红一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每一个服务运行在其独立的进程中，服务与服务间采用轻量级的通讯机制互相协做（一般是基于HTTP协议的RESTful API）。每一个服务都围绕着具体业务进行构建，而且可以被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。］

　　［敲黑板］在这里有一个很大的概念误区（起码我之前是混淆的）：“微服务”和“微服务”架构，这是两个不一样的概念，他们有着本质的区别：“微服务”强调的是服务的大小，它关注的是某一个点，而“微服务架构”是一种架构思想，须要从总体上对软件系统进行考量。我以前曾经看过一段颇有名的评论：

 

　　［Chris Richardson说：“ 微服务”是一个很糟糕的名字，它致使开发人员建立了许多粒度很小的服务，每一个服务拥有一个单独的REST端点。不只如此，这个名字还暗示了微服务在开发者心目中的重要位置。例如，人们会说“咱们能够用微服务来解决这个问题”；我也看到了愈来愈多的“某某微服务框架”，而实际上，这些框架跟微服务架构不必定有太多联系，它们只是简单的Web框架（如：spring-boot）。使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协做的服务组织成一个系统来支撑业务。］

 

OK，当咱们理解了什么是微服务架构以后，咱们再来从新分析一下我上面的那个单体式应用架构图，我对它作了一些修改：

　　我将原来的一个很大的复杂war包拆成了一系列的简单的应用，每一个应用只关注本身的业务：好比，对于手机用户，对于pc用户不一样用户，设备和特殊场景，都分别部署不一样的应用服务。

　　每个后台服务开放一个REST API，好比API1，API2...n，外界同API不能直接进行交互，须要经过API网关来传递消息。API网关负责负载均衡，缓存，ACL，计费，监控等等。

　　不一样的服务之间，好比API1和API2之间也会有访问与被访问的关系，咱们在后续章节再讨论这部分。

---

• 本章总结

　　对比个人第一张架构图和第二张架构图，我认为从架构演变来讲，有如下几点：

1. 图1的全部服务出口单一，图2服务出口有多个，根据设备的不一样，需求的不一样，能够分离维多个出口；
2. 图1的业务是集合的，只能经过复制备份的方式横向扩展，图2业务是非耦合的，尽量在单一服务中处理单一集中性业务，不掺杂其余无关业务；
3. 图1代码修改后，须要把全部服务器从新部署一遍；图2只须要针对性的部署修改的具体服务，其余无关服务不须要变化。

好了，因为篇幅关系，今天咱们就讨论到这里，欢迎你们讨论和建议；若是感兴趣的话，请关注后续文章：）

以上。