通过本篇文章您可以了解到以下内容:
- 微服务架构的由来、历史
- 微服务架构相比传统巨石应用的优势
- 微服务拆分原则概述
微服务架构的由来、历史
从软件架构的发展趋势来看，大体可以整体分为四个阶段:
![]()
前三个阶段分别是巨石应用、3-Tier架构、SOA架构:
- 巨石应用，顾名思义是将所有的业务逻辑用一个工程进行表示。（在上一篇文章中我们进行了详细的介绍）
- 3-Tier架构，一种软件设计的思想。不同于巨石应用的模式，它将整个业务应用进行了层次划分。总共分为三层，自上而下分别是表示层、业务逻辑层、数据访问层。另一方面，这种层次的区分也体现了“高内聚低耦合”的思想。
- SOA架构，一种软件设计的思想，按照实际业务需要，拆分成粗粒度、松耦合的服务架构。
第四个阶段也就是我们今天的主角，微服务架构。在谈到微服务架构的历史，我们就不得不想到了以下几位大师:
- Adrain Cockcroft，Netflix架构师。主导了Netflix从2009年到2016年巨石应用到微服务架构演进的工作。并使得Netflix成为首批成功从巨石应用迁移到基于云的微服务架构的公司之一。
- Fred George，在2012年的一次技术大会上，详细介绍了他和他的团队如何将百万级代码的传统应用进行改造拆分，并利用消息中间件（MQ）进行服务之间解耦的过程。
- Martin Fowler，2014年发表了一篇关于微服务架构的文章，这篇文章深入全面的介绍了微服务架构。（链接）
另外对于云原生概念最早的提出者Pivotal(已经回归到了VMware)对于微服务也给出了相关解释和说明:
![]()
（部分截取，详细内容可参见官网: https://tanzu.vmware.com/microservices ）
以上就是关于微服务架构历史的介绍，接下来让我们看看微服务架构相比传统巨石应用的优势又有哪些？
微服务架构相比传统巨石应用的优势
在上一篇文章中我们阐述了传统巨石应用在项目早期阶段的优势，以及在随着项目不断发展、扩大后显现出的弊端。那么相对于传统巨石应用，微服务架构的优势又有哪些呢?
![]()
- 应用程序扩展性（相比传统巨石应用架构，微服务架构下，每个微服务具备自主运行的能力，这使得添加、删除、更新、扩展单个具体服务变得相对容易。这种改变并不会影响到其他服务）。
- Two-Pizza团队（每个微服务的所有权分配给一个小团队，团队与团队之间紧密合作。从而大大提高了工作效率，也使得团队易于管理）。
- 数据安全性（在微服务架构中，每一个服务具有自己独立的数据。当微服务之间建立数据连接时，信息安全就会成为一个问题。幸运的是，大多数通信使用的是安全API。安全的API通过确保只有经过专门授权的应用程序、用户和服务器才能访问数据，从而保证了数据的安全性）。
- 快速迭代、交付、验证（微服务最重要的优势是灵活性，能够快速迭代一个小的、集中的功能，并看到结果。由于企业可以快速开发和部署新功能，用户可以在几周内看到他们的反馈，而不是几个月或几年。这大大促进了用户、开发人员和工程师之间的协作）。
- 技术多样化（不同的团队可以使用不同的编程语言以及技术来实现他们的服务。服务与服务之间通过声明式的API进行交互，大大增加了技术的灵活性）。
- 容错性（在微服务架构中，一个服务的故障不太可能对其他服务产生太大的影响，因为服务与服务之间是彼此独立运行的。然而大型分布式微服务体系结构往往具有许多依赖关系，因此需要避免的是当某个服务出现故障，因为依赖关系所导致的其他服务不可用的情况，即容错性）。
微服务拆分原则概述
通过上面一章节的介绍，相信我们清楚的了解了微服务架构的优势。当某一个新业务需求到来或者说对现有老旧的巨石应用进行改造时，我们是否可以直接通过某种已经选定的技术框架，就能够进行业务开发了呢? 答案是否定的。相比技术框架的确定以及具体的开发工作，更前置一步需要我们进行解决的就是微服务的拆分。
![]()
这里可以把它归结为“三步走”方式：
- 第一步（微服务拆分）此步骤可以分为两种情况。第一种情况即新的业务从0到1的构建。第二种情况即对已有的“巨石”应用进行改造，改造成微服务架构。
- 第二步（技术选型）此步骤相对比较好理解，根据不同的业务模块的特点以及需要，可以使用不同的技术框架。这里不同于巨石应用，因为每一个微服务是独立开发、部署的，所以在技术选型上面会更加灵活多样化。例如针对JAVA技术栈，我们可以使Spring全家桶，在已经拆分好微服务的前提下，帮助我们从技术框架的角度快速搭建微服务架构。
- 第三步（业务开发）相关的开发人员根据业务需求，在相应技术框架的基础上进行业务的开发、测试、部署等操作。
从上面的介绍不难看出，微服务拆分在整个流程中是尤为重要的，但是只要谈到微服务拆分，相信大家都会听说一个名词，它就是Domain Driven Design（领域驱动设计，简称DDD）。Domain Driven Design 起源于Eric Evans发表的书籍《DOMAIN-DRIVEN DESIGN TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》（中文译名《领域驱动设计—软件核心复杂性应对之道》。在此书中的一些概念，例如领域、限界上下文等概念和微服务倡导的高内聚、低耦合有着完美的契合，进而越来越多的人把Domain Driven Design作为微服务拆分的一种指导原则。
![]()
如上图所示，我们可以看到包含了众多概念，想要理解掌握这些概念并做到灵活运用并不是一件容易的事情，同时Domain Driven Design是一种软件系统设计和开发的方法论，是一种指导思想。如何根据这种指导思想并结合有效的分析工具进行实际落地，成为了大家普遍关注的问题。
那么作为云原生概念的提出者Pivotal（VMware）在微服务拆分上的最佳实践是什么?最佳实践过程中又会结合使用哪些工具?
在下期的文章中会继续和大家进行交流分享，敬请期待! 如您有任何建议，欢迎随时联系我们!
参考链接:
- https://martinfowler.com/articles/microservices.html
- https://tanzu.vmware.com/microservices
来源｜公众号：VMwareTanzu云原生
