微服务这一词这几年特别特别火，经常能在各种公众号和视频里看见它。以后软件开发也是这个趋势。今天就来简单记录一下它。
在介绍微服务前，我们先回顾一下以前的软件开发是怎样的模式。
简单说就是一个单体架构，以javaweb开发为例，将一个应用分为web层、service层、dao层，以及各种公用代码块。每一层各司其职，层与层之间相互调用。最终处理浏览器发来的请求。
在学习了SpringBoot之后，我们构建一个应用程序的速度是非常快的，(如果只涉及增删改查的话)。因为约定大于配置，它帮我们免去了很多繁琐的xml/注解配置。
但这种单体的应用程序有一个问题，当应用的访问量高了以后，服务器它顶不住呀。
问题来了
这里举一个例子:试想一下，一个电商平台它会有很多模块吧(用户模块、订单模块、商品模块、购物车模块...),几个模块都堆在一个工程里面写，用户在浏览器先登录验证，那要先发请求到服务器里，验证之后再返回结果给浏览器，之后浏览商品，又发一个请求到同一个服务器里，处理完成后在返回结果给浏览器，之后…
几个用户还可以接受，如果碰上双十一，六一八这样的购物节，几十万上百万的用户所有请求都往同一个服务器里面发，那服务器不崩了才怪勒。
社会都是由需求推动的嘛！
这个时候有那么一个大神提出了微服务这一词，就是今天的主角,并发表了一篇论文，详情可以查看Martin fowler的官网
关于这一概念，网上有很多解读了。今天就以直白的话语讲解一下下。
微服务就是专注于服务本身。以往我们将所有的模块都堆在一个应用里面。但是现在，我们会把模块拆出来，不同的模块放在不同的服务器里。
换个说法，以前所有代码都写在一个project里面，现在我们一个project只写一种模块的代码。假设AProject写用户模块的代码，那BProject写订单模块的代码，以此类推。
那不同的project之间怎么调用呢?比如电商平台里，一个用户要查询购物车里有什么东西，它向浏览器发送一个查询请求，这个请求经过一系列的操作，来到了专门处理购物车模块的shopping project里面。它接受到了查询请求，但是你总要告诉我是要查询哪一个用户的购物车吧?于是浏览器发送请求时还需要带上当前用户的信息(比如用户id)。购物车拿到这个用户信息后，就远程调用专门处理用户模块的project，得到用户的具体信息后，知道你是谁了之后，就再去查询该用户下的购物车。
扯了这么多，其实不同的模块之间是通过远程调用的。为什么前面加一个远程呢?因为呀，不同的模块即project是部署在不同的服务器上的。服务器都不同了，那互相调用的话加一个远程二字也不过分吧?
讲到这里了，不知道大家发现没有，前面那个电商平台的问题已经解决了。现在一个电商平台的很多模块(用户模块、订单模块、购物车模块、商品模块...)都部署在不同的服务器上，这样所有的用户请求原本往一个服务器走，现在被分了出去。和用户有关的请求往部署了用户模块的服务器上走，别的也同理。
这样子，一个系统的健壮性大大增加。服务器由单个变成了服务器群。处理起高并发也得心应手了。
到这里先小总结一下:
微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务独立部署，服务之间相互配合、相互协调，每个服务运行于自己的进程中。
微服务的优缺点
每一个东西都有两面性，微服务也一样.
优点:
- 每个服务足够内聚，足够小，比较容易聚焦
- 开发简单且效率高，一个服务只做一件事情
- 开发团队小，一般2-5人足以（当然按实际为准）
- 微服务是松耦合的，无论开发还是部署都可以独立完成
- 微服务能用不同的语言开发
- 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等）
- 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
- 微服务允许你融合最新的技术
- 微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合。
- 每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活。
缺点:
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也会增大
- 依赖系统部署
- 服务间通讯的成本
- 数据的一致性
- 系统集成测试
- 性能监控的难度
总的来说，微服务是未来软件开发的趋势了。他的硬件开销也不高，大公司可以使用它的理念来解决高并发的问题，小公司也因为它的成本低而完成架构的升级，进入分布式的行列。
最大的挑战应该是咱们准程序员和各位程序员吧，当一个新技术来临时，是危机也是机遇。我们需要把握住现在的趋势，现在java程序员只靠以前ssm怕很难走天下了。微服务也出现几年了，开源社区也算完善，咱们一起好好共勉吧～