0. 前言
我们先从 Nginx 说起，了解为什么需要微服务。最初的服务化解决方案是给相同服务提供一个统一的域名，然后服务调用者向这个域发送 HTTP 请求，由 Nginx 负责请求的分发和跳转。
这种架构存在很多问题：Nginx 作为中间层，在配置文件中耦合了服务调用的逻辑，这削弱了微服务的完整性，也使得 Nginx 在一定程度上变成了一个重量级的 ESB(Enterprise Service Bus)企业服务总线。
服务的信息分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试，服务消费方并不知道有哪些实例在给他们提供服务。这带来了一些问题：
(1) 无法直观地看到服务提供方和服务消费方当前的运行状况与通信频率；
(2) 消费方的失败重发、负载均衡等都没有统一策略，这加大了开发每个服务的难度，不利于快速演化。
服务的调用方在请求某项服务时首先通过中心组件获取提供服务的实例信息（IP、端口等），再通过默认或自定义的策略选择该服务的某一提供方直接进行访问，所以考虑引入 服务注册与发现(Euraka /Zookeeper)。
服务注册与发现 需要具备一下功能：
(1)调用中间层变成了可选组件，消费方可以直接访问服务提供方；
(2)服务信息被集中到 Registry 中，形成了服务治理的中心组件；
(3)通过 Monitor 监控系统，可以直观地展示服务调用的统计信息；
(4)服务消费者可以进行负载均衡、服务降级的选择。
1. 简介
通常而言，微服务架构是一种架构模式或者说一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务之间互相协调、互相配合，为用户提供最终的价值。
服务之间采用轻量级的通信机制（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底去掉耦合，每一个微服务提供单个业务功能，一个服务只做一件事。
微服务架构（分布式系统），各个模块/服务，各自独立出来，“让专业的人干专业的事”，独立部署。分布式系统中，不同的服务可以使用各自独立的数据库。
2. 特点
(1) 按照业务来划分服务，单个服务代码量小，业务单一，易于维护。
(2) 每个微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独立的进程中。
(3) 微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力。
(4) 微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务。单个微服务能够集群化部署，并且有负载均衡的能力。
(5) 整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。
(6) 整个微服务系统有链路追踪的能力。
(7) 有一套完整的实时日志系统。
3. 主要功能
(1) 服务的注册和发现。
(2) 服务的负载均衡。
(3) 服务的容错。
(4) 服务网关。
(5) 服务配置的统一管理。
(6) 链路追踪。
(7) 实时日志。
4. 优势
(1) 每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个只当的业务功能或业务需求。
(2) 开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成。
(3) 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
(4) 微服务能使用不同的语言开发。
(5) 易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Hudson、Bamboo。
(6) 微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值。
(7) 微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分离。
(8) 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
5. 微服务技术栈
微服务中，首先肯定离不开服务开发、服务配置与管理、服务注册与发现、服务的调用、熔断器以及负载均衡等等，除此之外，还有服务的路由、监控、部署，还有可能涉及到一些中间件等等。
6. 多架构融合
分布式：一个业务分拆多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上
微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互，微服务也是分布式的一种。
好的设计应该是分布式和集群的结合，先分布式再集群，具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样每个子业务如果出了问题，整个系统完全不会受影响。
