微服务虽然是当下刚兴起的比较流行的新名词,但本质上来说,微服务并非什么新的概念。
很多 SOA(面向服务的架构)实施成熟度比较好的企业,已经在使用和实施微服务了。只不过,它们只是在闷声发大财,并不介意是否有一个比较时髦的名词来明确表述 SOA 的这个发展演化趋势罢了。
微服务其实就是服务化思路的一种最佳实践方向,遵循 SOA 的思路,各个企业在服务化治理的道路上走的时间长了,踩的坑多了,整个软件交付链路上各个环节的基础设施逐渐成熟了,微服务自然而然就诞生了。
微服务
微服务是一种小型的、自主的、协同工作的服务。松散耦合和高内聚性是指微服务的两个概念。内聚性是将相关代码分组在一起的方式,而耦合性是指不同的服务如何相互依赖。软件工程大师RobertC.Martin对“单一责任原则”的定义是微服务的核心,它的定义是“将因相同原因而发生变化的那些事物聚集在一起,并将因不同原因而发生变化的那些事物分开。”
这两个概念推动了微服务的七个原则,允许团队独立地工作、部署、失败、交付和扩展。
面向服务的架构(SOA)旨在应对大型单片应用程序、代码的可重用性和维护方面的挑战。微服务是通过独立服务实现面向服务的架构(SOA)的一种方法,其中每个服务都充当组织业务领域的边界。在微服务架构中,每个更改都可以彼此独立地实现和部署,而无需用户更改。
微服务的原则
使用微服务时,常见的故障点是过早分解。在通常情况下,团队在与应用程序的用例相关的更改中会付出高昂的成本,或者初始服务边界是错误的。将应用程序分解为微服务通常是开始微服务之旅的最简单方法。
域驱动设计的原则
域驱动设计(DDD)是如何通过代码对现实世界进行建模。因此,域驱动设计(DDD)介于出色的代码和微服务成功之间。尽管有许多文献讨论了如何从战略和战术上实施域驱动设计(DDD),但在没有实践和指导的情况下,这仍然是一个相当复杂的话题。以下是利用域驱动设计(DDD)概念的入门方法。
首先必须理解,组织使用的任何代码都始于存在于域中的问题以及存在业务愿望的问题。因此,领域驱动设计的旅程始于领域专家和开发人员。通常,组织可能有多位领域专家一名开发人员或各种开发人员,但只有一名领域专家。无论组织结构如何,团队的目标都是着眼于全局并创建所谓的场景地图。
构建场景映射时,组织可以通过了解问题空间、发现通用语言并为系统创建表示模型来提取领域知识。系统由代表问题空间的域和子域组成。这些域在场景映射中称为场景,并且可以描述组织内的不同系统。例如,组织可能需要表示一个销售场景和客户支持场景,以对处理食品包装厂的销售和客户支持的新软件应用程序进行建模。
示例场景映射
这些域为组织提供了有关如何创建有限场景的好主意。有界场景表示属于系统的服务,它封装并定义了该模型的特定职责。创建有界场景就是要建立一个边界,在这个边界中,域语言在这个空间中不会造成混淆的问题。
定义有限的场景、通用语言和场景映射可以使组织在使用微服务时专注于全局。域驱动设计指导开发人员讨论系统设计时,因为组织经常在寻找通过代码表示真实世界的方法。域驱动设计(DDD)对于不熟悉特定领域的组织或开发人员,或者对于希望将其应用程序分解为微服务的组织而言,域驱动设计(DDD)尤其有用。
清洁代码
微服务成功的最后一件事是如何维护和使用组织的代码。有许多建议可以鼓励持久和可理解的企业代码库。它们中的一些引入了额外的权衡,但通常的经验法则是避免对不断增长的代码库感到自满,并寻找对组织有用的做法。
维护干净的代码库是域驱动设计(DDD)、微服务以及编写Kubernetes或云原生应用程序所不可或缺的。正如Kubernetes、微服务和域驱动设计(DDD)影响组织设计代码的方式一样。希望这些解释能够说明其应用程序是如何由相互重叠和互补的层组成的,从而形成一个有效且成功的系统。
结语
许多投资Kubernetes计划的组织都希望通过微服务获得成功。本文展示了如何通过微服务获得成功。拥有如此多的工具、流程和原则来管理流程可能会很困难,尤其是当最终客户无法获得频繁的软件交付时。持续交付可帮助组织交付价值、管理微服务部署、定义发布和回滚策略,并降低微服务的总体成本。
Copyright © QY Network Company Ltd. All Rights Reserved. 2003-2018 群英 版权所有 茂名市群英网络有限公司
增值电信经营许可证 : B1.B2-20140078 粤ICP备09006778号-36 粤公网安备 44090202000006号 粤工商备P091701000595