对于微服务的基本理解

讲起“微服务”概念，必须是要从“系统架构”演变说起。

互联网的不断兴起，系统架构从【单体应用架构】—>【垂直应用架构】—>【分布式架构】—>【SOA架构】—>【微服务架构】—>【服务网格化】……不断演变和升级

（一）微服务架构介绍

是在2014 年 由 Martin Fowler 提出的一种新的架构形式。

微服务架构是一种 架构模式 ，提倡将单一应用程序划分成一组小的服务，服务之间相互协调，互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制(如HTTP或Dubbo)互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中；

另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的 语言、工具(如Maven)对其进行构建。

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程。类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

【本质】--- 用一些功能比较明确、业务比价精炼的服务去解决更大、更实际的问题。

（二）传统开发模式和微服务的区别

传统开发模式：单体应用架构

实现方式：所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个容器里，包含了 DO/DAO，Service，UI等所有逻辑，做成一个web项目，然后部署到一台tomcat服务器上。

 

优点：

• 项目架构简单，小型项目的话， 开发成本低

• 项目部署在一个节点上， 维护方便

缺点：

• 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

• 项目模块之间紧密耦合，单点容错率低

• 无法针对不同模块进行针对性优化和水平扩展

**微服务架构设计**： 

目的： 有效的拆分应用，实现敏捷开发和部署

优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

• 微服务之间采用Restful等轻量级http协议相互调用

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）

 （三）