前言
记得大概在几个月前，偶然听到了微服务这个新鲜的名词，本着热爱学习的态度，开始到网上搜索相关知识，然后逐渐入坑。。。。
简介
近年来，微服务在应用开发和部署方面取得了显著的进步。将应用开发或者重构成微服务以分离服务，通过 API 以明确的方式来相互“对话” 。例如，每个微服务都是自包含（self-contained），各自维护自己的数据存储（这非常有意义），可以独立更新其他服务。
为什么需要学习微服务架构
单体应用
按照以前的开发模式开发出的应用我们称之为单体应用，通常就是把项目分为几个模块开发，然后打包成一个war包部署到WEB服务器上。这种做法很常见。他们很容易开发，因为我们的 IDE 和其他工具就是专注于构建单体应用。这些应用程序也很容易测试，同样也很容易部署。
单体地狱
在项目的早期阶段，单体应用可以良好的运行。但它存在很大的局限性。通常，我们的项目随着时间的推移，功能越来越丰富，代码、依赖自然也越来越多，时间一长，当我们尝试更新应用或者修复BUG时，将会感到非常困难并且耗时。应用启动时间边长、需要重新部署整个应用才能更新其中的一部分、任何模块出现问题都有可能拖垮整个应用、采用新框架或语言变得非常困难都是单体应用的缺点，也是非常不符合敏捷开发和交付的要求的。
使用微服务来解决
使用微服务架构模式就可以解决上面提到的问题。它的主要思想是：将一个应用分解成较小的互联服务。一个服务通常只实现一组功能，每个服务都是一个小应用。一些微服务会暴露给其他服务或者客户端访问的API。通常每个微服务实例都是一台虚拟机或者是一个Docker容器。
客户端通常不会直接访问服务，而要通过API网关。API 网关负责负载均衡、缓存、访问控制、 API 计量和监控。（API网关的介绍之后再谈）
下面是一个单体应用拆解为微服务的案例：
上图中服务间的通信通过REST API来完成，其实还可以是RPC、消息队列等。
微服务与单体应用对比
微服务的优点
- 解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务，虽然功能数量不变，但是应用程序已经被分解成
可管理的块或者服务。 - 每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合服务 API 设计规范的技术。这也就意味着开发人员不再有可能在新项目开始时使用过时的技术。
- 微服务架构模式可以实现每一个微服务独立部署、独立扩展。并且使得
持续部署成为可能。
微服务的缺点
一项技术，有优点就必然有缺点，同世间万物一样。我们不但需要了解它们的优点，同时也要了解它们的缺点，这样我们才能在合适的场景中做出更好的选择。下面我们列出微服务的几个缺点：
- 微服务的规模不好把控。我们究竟该把应用分成几个服务，每个服务的规模到底应该怎么度量。如果分的过小，那么会极大的增大系统的复杂度，但如果分的过大，右无法充分体现微服务的优势。
- 微服务是一个分布式系统， 其使得整体变得复杂。不像单体应用，如果一个模块需要访问另一个模块的功能，我们直接调用即可，但是在微服务架构中，由于每个服务都可能部署在不同的服务器上（或者Docker容器），那么我们就需要选择和实现基于消息或者 RPC 的进程间通信机制。
- 数据库的设计。通常每个服务都会维护自己的数据库，有些功能可能需要更新多个实体，即更新多个服务的数据库。
- 服务的发现机制。通常每个服务都有多个运行时实例。我们需要保证服务能够发现需要与之通信的任何其他服务的位置（主机和端口），这样才能通信。
其实微服务需要解决的问题还有很多，就不细说了，但目前都已经有比较成熟的解决方案，我们无需担心需要自己来实现某些复杂功能来解决上述问题。希望有一天我们都能够掌握微服务相关核心技术，加油！！！
[1] Chris Richardson, Floyd Smith, 微服务：从设计到部署
[2] John Carnell, Spring微服务实战
