微服务架构设计方案.docx

微服务架构设计方案 引言：“微服务”是当前软件架构领域非常热门的词汇，能找到很多关于微服务的定义、准则， 以及如何从微服务中获益的文章，在企业的实践中去应用“微服务”的资源却很少。本篇文章中，会 介绍微服务架构（Microservices Architecture）的基础概念，以及如何在实践中具体应用。 单体架构 (Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构 中去。比如：常见的 ERP 、 CRM 等系统都以单体架构的方式运行，同时由于提供了大量的业务功能， 随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。 单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，然后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。 图 1：单体架构 大部分企业通过 SOA 来解决上述问题， SOA 的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于 SOA 架构的应用可以理解为一批服务的组合。 SOA 带来的问题是，引入了大量的服务、消息格式定义和规范。 多数情况下，SOA 的服务直接相互独立，但是部署在同一个运行环境中 （ 类似于一个 Tomcat 实例 下，运行了很多 web 应用 ） 。和单体架构类似，随着业务功能的增多 SOA 的服务会变得越来越复杂， 本质上看没有因为使用 SOA 而变的更好。图 1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。 单体架构的应用一般有以下特点：  设计、开发、部署为一个单独的单元。  会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难  很难以敏捷研发模式进行开发和发布  部分更新，都需要重新部署整个应用  水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难 （部分服务需 要更多的计算资源，部分需要更多内存资源）  可用性：一个服务的不稳定会导致整个应用出问题  创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上 微服务架构（Microservices Architecture） 微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。 多数人对于微服务的定义是， 把本来运行在单体架构中的服务拆分成相互独立的服务，并运行在各自的进