本文摘自网上

1.什么是微服务？

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。微服务架构风格是一种将单个应用程序开发为“一套小型服务”的方法，每个服务“运行在自己的进程中”，并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务“围绕业务功能构建”，并通过全自动部署机制“独立部署”。“这些服务只有最低限度的集中管理”，可能是用不同的编程语言编写的，并使用不同的数据存储技术。
概念： 把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义： 围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质： 用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

简单说就是将一个完整的应用（单体应用）按照一定的拆分规则（业务领域拆）拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。服务与服务之间通过http，消息，rpc等方式进行调用和通信。

2.为什么出现微服务？

2.1微服务的出现与发展

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
（1）RPC
Remote Produce Call远程过程调用，类似的还有RMI 远程方法调用。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表。
（2）HTTP
http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

2.2 系统架构的演变

2.2.1 传统开发模式——单体架构

一个系统业务量很小的时候所有的代码都放在一个项目中就，然后这个项目部署在一台服务器上。整个项目所有的服务都由这台服务器提供。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。这就是单体结构。

(1)优点：
①　开发简单，集中式管理
②　基本不会重复开发
③　功能都在本地，没有分布式的管理和调用消耗
④　部署成本低：把写好的项目打成包，在tomcat服务器上面部署一下，用户就可以访问了，如果用户访问多了，那就在加两个服务器，形成负载均衡的集群。
(2)缺点：
①　耦合度高：在大型项目的开发中，像拼多多，淘宝这些，一个大型项目里面有很多的功能模块，代码量十几万行甚至于几十万行代码，如果使用单体架构。打包部署就可以需要很久，效率太低。所以在大型项目中基本上都是采用分布式架构。
②　效率低：开发都在同一个项目改代码，相互等待，冲突不断
③　维护难：项目中的功能模块的代码你中有我，我中有你，假设其中一个模块中出现问题，其他模块也会受到影响，代码的边缘化也越来越模糊。代码功功能耦合在一起，
④　不灵活：构建时间长，任何小修改都要重构整个项目，耗时
⑤　稳定性差：一个微小的问题，都可能导致整个应用挂掉
⑥　扩展性不够：无法满足高并发下的业务需求

2.2.2分布式架构

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。
（1）优点
①　降低服务耦合:每个功能模块，都成为了单独的项目，大家各写各的项目，没有过多的牵扯耦合度就会大大的降低，另外像打包速度，代码量都会减少。
②　有利于服务升级和拓展：像以后功能模块项目/服务进行升级维护也影响不了别的功能模块项目的正常进行。
（2）缺点：
服务调用关系错综复杂：一个大型的项目被拆分许多的服务，各个服务的功能模块该如何调用？许多的服务部署起来也是比较麻烦。（就是说一个大型项目被拆分为许多的服务，该如何拆分哪几个服务作为单独的模块，那些业务不需要拆分，这个拆分的粒度需要把握）
服务之间如何实现远程调用（各个服务之间该如何进行远程调用呢？）？
为了解决这些问题，人们需要制定一套行之有效的标准来约束分布式架构。出现了各种各样的技术（如下图）去解决这些问题：但是近几年运用最广泛的就是微服务。

2.2.3 微服务架构

微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征（微服务它还是一种分布式架构，只不过人们在设计分布式过程中踩坑，不断的总结经验，得到了良好的分布式架构实践方案）
微服务特点：
1、分布式服务组成的系统
2、按照业务，而不是技术来划分组织
3、强服务个体和弱通信（ Smart endpoints and dumb pipes ）
4、自动化运维（ DevOps ）
5、高度容错性
6、快速演化和迭代
微服务其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合

2.2.4 小结

单体架构特点： 简单方便，高度耦合，扩展性差，合适小型项目。如:学生管理系统。
分布式架构特点： 松耦合，扩展性好，但架构复杂，难道大，适合大型互联网项目。如:京东、淘宝
微服务： 一种良好的分布式架构方案。
优点：拆分粒度更小、服务更独立、耦合更低
缺点：架构非常复杂，运维、监控、部署难度更高

3. 如何实现微服务？

微服务容器化部署的一般流程和总体方案：主要分为微服务开发、微服务容器镜像构建、微服务容器镜像管理、微服务容器编排管理四个步骤。

3.1 微服务开发

随着企业和开发者对微服务的不断研究，微服务开发框架层出不穷，如 SpringCloud，Dubbo 等，其丰富的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式回话和集群状态管理等操作为构建微服务系统提供了简单的开发模式。
企业或者个人进行应用开发时，可以通过对待开发应用的分析研究，拆分业务服务，选择合适的微服务框架进行应用开发，充分利用其自带的丰富组件，如服务注册和发现、网关 API、负载均衡、容错监控或其他第三方管理插件，通过简单的配置实现微服务应用的快速开发和系统管理。

3.2 微服务容器镜像构建

镜像构建是将开发的微服务生成可以运行的容器镜像。目前比较主流的就是使用Docker进行快速构建。Docker 中通常有两种方法来构建新镜像。第一种是通过 commit 命令将一个正在运行的容器提交为一个新镜像，第二种为编写 Dockerfile文件，接着使用 build 命令构建一个容器镜像。

3.3 微服务容器镜像管理

微服务容器镜像已经构建成功，但往往一个完整的应用系统包括不止一个微服务，即对应着多个镜像，因此还需要对构建的容器镜像进行相应的存储管理。
DockerHub 是 Docker 官方认证的DockerRegistry，上面不仅存放着许多常用的优秀镜像，还提供认证、工作组结构、工作流工具、构建触发器等工具来简化工作。
因此，对于每一个为服务应用，首先在 DockerHub 上创建相应的私有仓库，然后将应用下所有微服务构建好的容器镜像推送到仓库内，进行存储和管理。同时可以随时随地拉取相应的镜像，搭建新的开发、测试环境。

3.4 服务容器编排管理

通常拉取镜像进行容器启动后，该微服务就会运行到新创建的容器进程中。由于应用包括多个微服务容器，容器的启动顺序、运行容器间的通信，容器实例的运行状态都需要配置和管理，若都人工配置和操作，不免增加了许多部署人员和维护人员的工作量和复杂度，因此需要选用容器编排工具进行容器的管理和调度。
随着容器的应用越来越多，容器编排和集群管理工具也层出不穷，如 Docker Compose，Docker Swarm 和 Kubernetes。其中 DockerCompose 操作最容易，只需要编写一个文件，即 docker-compose.yml，在此文件中定义应用程序的服务、声明好要启动的容器，配置一些参数，然后运行 docker-composeup 指令便可，但是需要注意到，Docker-Compose 只能管理当前主机上的 Docker，并不能跨主机去启动其他主机上的 Docker 容器。
其中 Kubernetes 是
Google 的一个开源项目，基于其多年大规模容器管理技术，具有完备的集群管理能力，包括透明的服务注册和发现机制、可扩展的资源自动调度机制、强大的故障发现和自我修复能力、多粒度的资源管理能力、负载均衡，涵盖了包括开发部署测试运维监控在内的多个环节。可实现大规模、分布式、高可用的 Docker 集群。