微服务架构介绍

1.简介

　微服务架构风格是一类将单一应用程序作为由众多小型服务构成之套件加以开发的方式，其中各项服务都拥有自己的进程并利用轻量化机制（通常为HTTP源API）实现通信。这些服务围绕业务功能建立而成，且凭借自动化部署机制实现独立部署。这些服务匹配一套最低限度的中央式管理机制，且各服务可通过不同编程语言编写而成并使用不同的数据存储技术。
　要解释微服务风格，那么首先应当将其与整体风格进行比较：整体应用程序作为单一单元进行构建。企业级应用程序通常包含三个组成部分：一套客户端用户界面（由运行在用户设备上的浏览器中的HTML页面以及Java代码构成）、一套后端数据库（将大量插入至数据库管理系统的大量表构成，通常采用关系数据库）以及一款服务器端应用程序。该服务器端应用程序将负责处理HTTP请求、执行域逻辑、对来自数据库的数据进行检索与更新，同时选定HTML视图并将其发送至浏览器端。此服务器端应用程序通常为单一的逻辑可执行文件。任何针对该系统的变更都需要对该服务器端应用程序进行新版本构建与部署。
　这样的整体服务器机制在构建此类系统中可谓不可或缺。我们用于处理请求的全部逻辑都运行在单一进程当中，允许大家使用语言中的基本功能以将该应用程序拆分为类、函数以及命名空间。通过这种方式，我们能够在开发人员的笔记本设备上运行并测试应用程序，同时利用一整套部署流程以确保全部变更都经过妥善测试而后被部署在生产环境当中。大家可以将大量实例运行在一套负载均衡方案之后，从而实现横向扩展能力。
　　这类整体应用程序当然能够切实起效，但人们却逐渐发现其中存在着诸多弊端——特别是在将大量应用程序部署在云环境当中的情况下。由于变更周期被大量集中于一处——即使仅仅指向应用程序中的一小部分，单一变更亦要求我们对应用程序整体进行重构与重新部署。随着时间推移，我们往往很难保证理想的模块化结构，这意味着本应只影响单一模块的变更往往会扩散至该模块之外。规模伸缩亦要求我们对整体应用程序进行规模调整，而非单纯为其中必要的部分进行资源扩容。
　正是这些弊端造就了如今的微服务架构风格：即以服务套件的形式构建应用程序。除了各服务能够单独进行部署与规模伸缩之外，每项服务还具备牢固的模块边界，甚至允许我们在不同的服务当中使用不同的编程语言进行代码编写。另外，各服务亦可由不同团队负责管理。

2.微服务特性

• 通过服务实现组件化

  　对组件做出的定义是，其属于软件中的一类单元，且具备可更替性与可升级性。
  　微服务架构会使用这些库，但其实现组件化的主要手段则是将软件拆分成多个服务。我们将“库”定义为与程序相对接且可通过内存内函数调用发挥作用的组件，而“服务”则为进程之外的组件，其可通过Web服务请求或者远程程序调用等方式实现通信

• 围绕业务功能构建组织

  　拆分为一系列独立的服务——且各服务间通过一套消息收发总线实现通信

• 产品而非项目

  　采用“谁构建，谁运行”原则，其中开发团队需要对生产环境下的软件成果承担全部责任。这就要求开发人员在日常工作中全程关注其软件的生产运行情况，同时掌握来自用户的反馈意见，意味着他们需要在一定程度上为用户提供技术支持服务。
  　产品的定位应始终与业务功能相协调。相较于以往将软件视为一整套已经完成的功能集的心态，微服务架构要求我们全程与之保持关联，并思考该软件能够如何协助用户加强业务功能。

• 智能化端点与傻瓜式流程
  　智能化端点与傻瓜式流程。采用微服务架构的应用程序旨在尽可能实现解耦化与关联性——它们各自拥有自己的域逻辑，而且在经典Unix场景下的运作方式更像是过滤器机制——接收请求、应用合适的逻辑并生成响应。这一切都通过简单的REST类协议实现编排，而非经由WS-Choreography或者BPEL等复杂协议以及中央编排工具实现。
  　微服务团队采用这样的原则和规范：基于互联网（广义上，包含Unix系统）构建系统
  　第二种做法是通过轻量级消息总线来发布消息。