微服务架构设计方案.pdfVIP

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