好久没有写文章了，主要是每天闲下来的时间太少，好不容易这个周末闲下来没什么事情，于是就买了《Spring Boot实战》和《Spring Cloud微服务实战》两本书来学习一下微服务架构，也算是为后面的项目做准备或者技术储备吧。下面放一张两本书的照片，省得想看的人找不到，个人感觉这两本书相当不错，想了解微服务架构这两本书加实践就足够了。
我也只是走马观花看了一遍全书，然后回来跟着书一点点实践了一部分，了解的还不是很深入，所以哪里有理解不正确的地方欢迎指正。这篇文章主要是对微服务和微服务架构了解个大概，下一篇会写深入一点的比如自定义配置等内容。
Spring Boot
要了解微服务架构，首先要了解的就是Spring Boot。这里吐槽一下，java这个Spring终于出了个让我不恶心的东西，就是这个Spring Boot。因为我之前搞的是.net一套，后来接触java别的没感觉啥，就这配置文件一堆一堆真是让我恶心透了。
可能Javaer们要喷我，说什么.Net很简单啊，项目一新建就可以用啦，没啥技术含量。其实何必呢，好比你打电话点一份披萨，Spring以前是什么情况？开始就是告诉厨师怎么做、放什么调料、怎么放、放多少等等啥都你去决定。而.net呢？直接就是给你一个对应口味的披萨，需要定制可以自己提。
所以吧，不是说配置文件多是毛病，只是大多数人用框架的目的就是上来就写业务代码，给我个默认配置好的就好了，哪里不合我意我就改哪里。
Spring Boot就做的很好，省去了很多麻烦的XML配置，一切依赖项直接在Maven配置文件的dependencies里面加上，内部就自动给你配置好了。这也就是为什么它很适合作为微服务的原因之一。
另一个原因就是它可以自宿主，也就是可以不需要tomcat，直接运行。执行Maven Install之后会生成jar可执行程序，直接在命令行执行 $java -jar ***.jar 就可以通过浏览器访问了。当然，也可自己配置生成war包，然后在tomcat中运行。
Spring Boot的优点不止这些，还有起步依赖、Spring Boot CLI、Actuator等，而且虽然很多东西都已经配置好，但是也可以自定义配置来覆盖默认配置，并且都是通过写代码的方式而不是XML配置文件的方式。总之它是一个为微服务而生的轻量级框架。
关于Spring Boot的初体验可以从start.spring.io开始。
Spring Cloud 微服务架构
上面介绍的Spring Boot是微服务，这里的微服务架构才是重点。那什么是微服务架构呢？
它的主旨是将一个原本独立的系统拆分成多个微小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以用不同的语言来编写----《Spring Cloud微服务实战》
先举几个实际情况来说说我为什么要考虑微服务架构：
1、 我们的整个系统目前是所有业务都在一个项目里面，而且不同客户对不同业务模块的需求和取舍都不同，每个业务模块也不能独立出来复用，这样就导致一个项目改来改去N多个版本，管理起来非常麻烦。
2、有些业务模块是非常重要且常用的，有些是不常用的，但在整个系统中一旦其中一个不常用模块出现问题可能会导致整个系统不可用。
3、团队中有人对业务A熟悉，有人对业务B熟悉，也有人对业务C熟悉。在这种情况下业务A、B、C都在一个系统中且有关联时往往会耦合性比较大，造成的沟通也比较复杂。除此之外，目前的模式是一个人设计以及分配任务给其他人，这样的问题是一个项目在设计初期一个人难以掌控项目全局，也就难以保证每个业务模块都能理解到位。
根据以上三点问题，通过微服务架构完全可以解决。如：
问题1：采用微服务架构，每个业务模块作为一个微服务，根据需求不断完善对应模块的API，这样可以局部更新且不影响其它模块也达到模块复用的目的。在应对不同需求只需调整前端页面和调用不同API，不必复制整个项目。
问题2：由于各个服务独立，所以会互不影响。
问题3：对于业务模块之间需要通信的，可以采用消息队列来实现，比如RabbitMQ。或者互相调用API来达到目的，具体方案要根据业务情况来确定。不同服务只需要约定好通信方式即可。
如果采用微服务架构就要做到根据业务模块来组织团队，也就是一个业务模块一个团队或一个人来负责每个负责指定业务模块的团队或个人用做“产品”的心态去做好需求设计以及开发。这样会大大减少沟通以及可能存在的设计问题。当然，这种分工形式对某个团队或个人要求比较高。
除此之外微服务还有很多特点，如：
相比单体项目，可以做到不同业务采取不同的技术方案以及技术平台，这样就不会出现杀鸡用牛刀或是杀牛用指甲钳的窘境了。就如书中所说的
不是每一个问题都是钉子，不是每一个解决方案都是锤子。
去中心化管理数据，每个微服务都有自有的数据库，这样做到去中心化数据管理。
统一的权限验证，Spring Cloud提供API网管来管理微服务接口并做到请求过滤的功能，这样就可以对多个微服务做到统一的权限验证，当然，每个微服务也可以拥有自己的权限验证。
微服务虽然增加了运维难度和架构上的复杂性，整体来说对于我这种情况的单体项目是利非常大于弊的。
对于微服务架构的简单介绍以及应用场景就介绍到此，下一篇将会根据我的初步实践总结一下Spring Boot相关知识。
