微服务架构介绍
微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。
微服务架构是一种软件架构模式，将单一应用程序划分成一个个小的服务，服务之间互相调用、或者通过网关调用运行。每个服务运行在其独立的系统进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的Rest API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到各个软件环境等。
微服务场景 在传统型应用系统中, 虽然区分业务模块与基础模块,但是不能做到每个服务独立运行与部署. 那么在后台将是一个统一的服务体，对外提供服务.在用户访问前端使用负载均衡进行4-7的负载. 后台采用缓存、数据库、共享存储进行数据的共享.
在业务代码更新过程中， 不可避免的会影响到其他业务的系统。 而在上线之前，一般都会经历测试的阶段, 但是在业务系统庞大之后，不论每次软件版本功能的更新大与小，测试都是无法全面测试的。有时候甚至是在当时上线没有发现问题，可能会在下次发布或者是在其他的操作过程中，才发现问题。这样处理问题的故障定位就会异常的复杂，不能快速准确的定位问题.
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是移动互联网现在最流行的软件开发框架。在微服务架构中，集中式业务服务管理几乎不存在，微服务使用轻量级HTTP接口进行通信。
在SOA 架构发展之后，相比Micro Service 能够基于框架快速的开发应用程序, 甚至都不需要专用的启动web 服务, 来启动微服务. 而自身的软件框架已经携带。
在各个软件运行环境中（测试、开发、生产），运维与开发人员经常需要修改不同环境的配置文件, 在操作中可能会因为失误导致服务异常的情况，经常发生. 之前的SOA架构如果需要实现配置中心功能，那么需要借助第三方的配置中心, 但是这一切相对于微服务而言，实现起来比较简单，包括一系列的服务治理(服务管理手段)方案，在框架中早已经集成，大大降低了开发人员的工作负载，使得软件开发人员只需要专注于业务逻辑开发，而不需要关心软件框架的内部实现。
在后期的容器云中，客户端使用http协议的方式，使得微服务框架能够非常方便的融入docker.并且通过docker 的ingress 功能实现对服务的弹性负载均衡.
微服务的优点和缺点 优点 优势复杂度可控(复杂度降低)
在将业务应用拆分之后，使原本复杂的应用，变得简单。每一个微服务只有单一的某一项功能，并通过定义良好的接口调用模式，使客户端调用更加简单。由于”体积”小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？主要原因如下：
部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）。
改动影响大，风险高（不论代码改动多小，成本都相同）。
因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）。
无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题。
微服务特点 微服务架构的特点：针对特定服务发布，影响小，风险小，成本低；频繁发布版本，快速交付需求；低成本扩容，弹性伸缩，适应云环境。
我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？简单总结如下：
部署，测试和监控的成本问题
分布式事务和CAP的相关问题
系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。