服务反模式深度解析：纳米服务与事务集成
纳米服务反模式
在大型项目中，如企业向SOA转型，很难提前规划好一切，往往需要先做出成果。以一个移动视觉识别/搜索引擎项目为例，首次发布采用了Knot方法，这种实现方式简单，基础设施投入少、集成灵活，使得项目在不到六个月内就推出了首个可用版本。这六个月不仅让团队更好地了解了业务领域，还能按业务需求的时间节点将所需功能推向市场，后续六个月又对系统进行了重写，应用了通信反转模式。
编码集成代码到服务中可能会产生Knot，在原型或首个版本中采用这种方式以快速展示成果是可以接受的，但需要做好重构规划，避免后续陷入困境。而服务粒度是形成Knot的因素之一，接下来要探讨的纳米服务反模式则与另一个粒度相关问题有关。
纳米服务反模式概述
确定服务的粒度是设计服务中最具挑战性的任务之一，需要平衡通信开销、系统灵活性、复用潜力等多方面因素。很难给出一个确切的方法来确定合适的服务粒度，因为“合适”取决于具体的上下文、环境和服务设计者的决策。相比定义什么样的应该是服务，定义什么样的不应该是服务更容易，例如，不应将整个现有ERP系统作为单个服务。纳米服务反模式则是指服务粒度过于细小的情况。
以常见代码示例中的计算器服务为例，一个基本的桌面计算器支持加、减、乘、除等简单操作。以下是一个Java计算器服务的WSDL文件部分内容，用于接收两个数字并将它们相加：
<wsdl:types> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns
