趋势
微服务是目前商业应用程序开发中最热门的新事物，它取代了敏捷、DevOps、容器化 和 RESTful，成为了所有简历和大会演讲中都必须提及的新的热门词。
如果你在搜索引擎中搜索中文【微服务】，得到4400万条结果：
我们再使用英文【microservices】搜索，得到248万条结果
上面的搜索结果充分说明，微服务确实是非常火热。
微服务的发展历史
微服务并不是一个突然出现的新技术。事实上 ，它是敏捷、DevOps 和 RESTful、分布式、SOA等等所有这些以前的概念的演化结果，是有望解决应用程序开发中许多长期存在的问题的方法。要了解此演变过程，我们需要回到最初，分析微服务是什么、它取代了什么，以及为什么它变得必不可少。
什么是微服务架构
从业界的讨论来看，微服务本身并没有一个严格的定义。不过，ThoughtWorks的首席科学家（Martin Flowler）的描述更加通俗易懂。
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
核心点包括下面几点：
- suit of small services:由一系列小服务组成，没错，“微”即是小;
- running in its own process:每个服务运行于自己的独立进程;
- built around business capabilities:围绕着业务功能进行建模;
- independently deployable:每个服务可进行独立部署;
- bare minimum of centralized management:最低限度的集中管理。
微服务的诞生背景
互联网行业的快速发展
互联网时代的产品通常有两类特点：需求变化快和用户群体庞大。在这种情况下，如何从系统架构的角度出发，构建理货、易扩展的系统，快速应对需求的变化；同时，随着用户的增加，如何保证系统的可伸缩性、高可用性，成为系统架构面临的挑战。
敏捷、精益方法论的深入人心
精益创业（Lean Startup）通过迭代持续改进，帮助组织分析并建立最小可实行产品（Minimum Viable Product）；
敏捷方法帮助组织消除浪费，通过反馈不断找到正确的方向；
持续交付帮助组织构建更快、更可靠、可频繁发布的交付机制；
云、虚拟化和基础实施自动化（Infrastructure As Code）的使用则极大简化了基础设施的创建、配置以及系统的安装和部署；
DevOps文化的推行更是打破了传统开发与运维之间的壁垒，帮助组织行程全功能化的高效能团队；
单体架构系统面临的挑战
- 庞大的代码库，关系错综复杂
- 编译构建时间很长，与持续集成配合麻烦
- 部署臃肿，影响部署速度与频次
- 扩展能力与弹性受限
- 新技术与工具框架使用会受限
容器虚拟化技术
Docker 是一个开源的应用容器（Linux Container）引擎，允许开发者将他们的应用及依赖包打包到一个可移植的容器中，然后发布到任何装有Docker的Linux机器上。
同传统的虚拟化技术相比，基于容器技术的Docker，不需要额外的hypervisor机制的支持，因此具有更高的性能和效率。另外，Docker的优势也主要体现在以下几个方面：
更快速地交付和部署。
更轻松的迁移和扩展。
更简单地管理。
Docker的出现，有效的解决了微服务架构下，服务粒度细、服务数量多所导致的开发环境搭建、部署以及运维成本高的问题。同时，利用Docker的容器化技术，能够实现在一个节点上运行成百甚至上千的Docker容器，每个容器都能独立运行一个服务，因此极大降低了随着微服务数量增多导致的节点数量增多的成本。
如果说之前的敏捷、精益、持续交付以及DevOps是微服务诞生的催化剂，那Docker的出现，则有效解决了微服务的环境搭建、部署以及运维成本高的问题，为微服务朝大规模应用起到了推波助澜的关键作用。
微服务的特征
每个微服务都是业务完整的
对于每个服务而言，我们希望它处理的业务逻辑能够单一，在服务架构层面遵循单一职责原则。也就是说，微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
轻量级通信
服务之间应通过轻量级的通信机制，实现彼此之间的互通互联，互相协作。所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟悉的XML或者JSON，它们的解析和使用基本与语言无关、平台无关。
对于轻量级通信而言，通常基于HTTP，能让服务间的通信变得标准化并且无状态化。REST（Representational State Transfer），是实现服务之间互相协作的轻量级通信机制之一。
对于微服务而言通过使用语言无关、平台无关的轻量级通信机制，使服务与服务之间的写作变得更加标准化，也就意味着在保持服务外部通信机制轻量级的情况下，团队可以选择更适合的语言、工具或者平台来开发服务本身。
独立性
独立性是指在应用的交付过程中，开发、测试以及部署的独立。
在传统的单块架构应用中，所有功能都存在于同一个代码库中。当修改了代码库中的某个功能，很容易出现功能之间相互影响的情况。尤其是随着代码量、功能的不断增加，风险也会逐渐增加。
除此之外，当多个特性被不同小组实现完毕，需要经过集成，经过回归测试，团队才有足够的信心，保证功能相互配合、正常工作并且互不影响。因此，测试过程不是一个独立的过程。
当所有测试验证完毕，单块架构应用将被构建成一个部署包，并标记相应的版本。在部署过程中，单块架构部署包将被部署到生产环境，如果其中某个特性存在缺陷，则有可能导致整个部署过程的失败或回滚。
在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其他的服务不会产生影响。换句话说，服务和服务之间是独立的。对于每个服务，都有独立的代码库。当对当前服务的代码进行修改后，并不会影响其他服务。
从代码库的层面而言，服务与服务是隔离的。
对于每个服务，都有独立的测试机制，并不担心破坏其他功能而需要建立大范围的回归测试。
由于构建包是独立的，部署流程也就能够独立，因此服务能够运行在不同的进程中。
进程隔离
所有功能运行在同一个进程中，也就意味着，当对应用进行部署时，必须停掉当前正在运行的应用，部署完成后，再重新启动进程，无法做到对部署。如果当前某应用中包含定时任务的功能，则要考虑在什么时间窗口适合部署，是否先停掉消息队列或者切断与数据源的联系，以防止数据被读入应用程序内存，但还未处理完，应用就被停止而导致的数据不一致性。
为了提高代码的重用以及可维护性，在应用开发中，我们有时也会将重复的代码提取出来，封装成组件。在传统的单块架构中，组件通常的形态叫共享库。当应用程序在运行期时，所有的组件最终也会被加载到同一个进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着不同的服务能非常容易的被部署到不同的主机上。作为运行微服务的环境，我们希望它能够保持高度自治性和隔离型。如果多个服务运行在同一个服务器节点上，虽然省去了节点的开销，但是增加了部署和扩展的复杂度。
微服务架构其实是将单一的应用程序划分成一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试以及独立部署。
微服务架构与SOA
SOA概述
早在1996年，Gartner就提出了面向服务架构（SOA）。SOA阐述了“对于复杂的企业IT系统，应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务”，其目的是为解决企业内部不同IT资源之间无法互联而导致的信息孤岛问题。
微服务与SOA
实际上，微服务架构并不是一个全新的概念。仔细分析SOA的概念，就会发现，其和我们今天所谈到的微服务思想几乎一致。 相比传统SOA的服务实现方式，微服务更具灵活性、可实施性以及可扩展性，其强调的是一种独立测试、独立部署、独立运行的软件架构模式。
微服务不是银弹
微服务的问题
任何事情都是两面的，有好的优点，当然会存在弊端，微服务的缺点我的理解如下：
- 分布式调用造成的性能、延迟问题。
- 可靠性不好保证。
- 数据一致性难以保证。
- 整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做，调用链上怎么确定哪个点有问题，服务的SLA保障、性能、错误率、告警、这么多服务如何集成测试、交付容器如何上线等等问题。
何时不需要微服务
如果你的项目满足下面的条件之一，那么不需要微服务。
- 你的代码没有模块化
你的服务要求极高的性能
要求极低的延迟或者无法容忍服务间调用出错，比如广告、高频交易中负责关键路径的系统，最好把所有的模块都打包编译成为单体应用。不过，多数互联网的业务系统不属于此类。
没有一个好的容器编排系统
容器化几乎是微服务的先决条件，如果你没有一个好的容器编排系统帮你解决服务发现、负载均衡、弹性扩容、自动化部署等问题，运维上的负担就会大大超过微服务带来的好处。
微服务技术选型
- 框架:SpringBoot SpringCloud
- 容器编排:Kubernetes
- 服务注册与发现:eureka consul zookeeper
- 服务间通信:
- 同步通讯：gRPC + HTTP RESTful API
- 异步通讯：RabbitMQ
- 持续集成、部署:GitLab Jenkins Docker