微服务概述

1. 什么是微服务

软件架构是一个包含各种组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

微服务概念的起源来源于Martin Fowler的一篇知名博文”MicroServices“。

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自领域驱动设计（DDD： Domain Drive Design）。

简单的说，微服务是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于http的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储，业务开发，自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

2. 单体应用架构

如上图所示， 我们需要开发一个打车应用， 我们将乘客管理、账单管理、司机管理、行程管理、通知管理、支付管理等所有应用模块全部打包在一个应用程序中， 它提供了应用所有的功能。

单体应用程序的核心是由模块实现的业务逻辑，它定义了服务、领域对象和事件。围绕核心的是与外部世界接口对接的适配器。适配器示例包括了数据库访问组件、生产和消费消息的消息组件和 web 组件，它们暴露了 API 或者实现了一个 UI。

尽管有一个逻辑模块化的架构，但应用程序被作为一个整体进行打包和部署。实际格式取决于应用程序的语言和框架。例如，许多 Java 应用程序被打包成 WAR 文件并部署在如 Tomcat 或者 Jetty 之类的应用服务器上。其他 Java 应用程序是打包成自包含（self-contained）的可执行 JAR。类似地，Rails 和 Node.js 应用程序被打包为目录层次结构。

以这种风格编写的应用是很常见的。他们很容易开发，因为我们的 IDE 和其他工具专注于构建单个应用程序。这些应用程序也很容易测试。您可以通过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端（end-to-end）测试。单体应用同样易于部署。你只需拷贝打包好的应用程序到服务器。您还可以通过运行多个副本和结合负载均衡器来扩展应用。在项目的早期阶段，它运作良好。

3. 单体应用架构的缺点

由于单体应用架构将所有的应用功能全部部署在一起， 当某一个功能因为故障导致应用不能响应， 那么整个应用将无法使用， 特别对于互联网公司来说， 这样的故障会导致巨大的损失；另一方面， 当应用越来越大时，单体应用启动时间会越来越长， 而且会从某些程度上影响应用程序的性能。下面简单罗列了一些单体应用架构的缺点：

1. 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；

2. 代码维护难：代码功能耦合高，新人不知道何从下手，维护比较困难；

3. 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；

4. 稳定性不高：一个微不足道的小问题，可以导致整个应用宕机；

5. 扩展性不够：无法满足高并发情况下的业务需求。

4. 微服务的主要特点

相比较于单体应用架构和SOA架构，微服务架构的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

A. 细粒度的服务分解

服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。

B. 独立部署运行和扩展

每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

C. 独立开发和演化

技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

D. 独立团队和自治

团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

感想： 我们可以看到整个微服务架构的思想就如我们现在面对信息爆炸、知识爆炸是一样的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。

5. 微服务的优点

• 每个微服务都很小，这样能够聚焦一个指定的业务功能或业务需求。

• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

• 微服务能使用不同的语言开发，如Java、Python、PHP、C#等。

• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Travis CI等工具。

• 一个团队的新成员能够更快投入生产。

• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

• 微服务允许你利用融合最新技术。

• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。

• 微服务能够即时被要求扩展。

• 微服务能部署中低端配置的服务器上。

• 易于和第三方应用系统集成。

• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。

6. 微服务的缺点

• 微服务架构可能引入过多的操作；

• 需要提高DevOps应用技巧； 

• 对于开发和运维带来一定的挑战，需要付出双倍的努力；

• 分布式系统比单体应用架构复杂，且难以管理；

• 对于故障诊断比较难，分布式部署跟踪比单体架构复杂；

• 当服务数量增加，管理复杂性增加。