中汽创智科技有限公司 – 基础软件部门
文章转载请注明作者、出处以及版权声明。未经授权，禁止用于商业目的。本文章仅代表作者观点，不对其中包含或引用信息的准确性、可靠性或完整性提供任何明示或默示的承诺及保证。对于任何直接或间接采用、转载本文章信息产生的损失，作者不承担任何责任。
联系
如果您对本文档内容有任何建议，请发邮件至以下邮件列表。
邮件列表：
like@t3caic.com
autosemo-info@caam.org.cn
| 专业术语 | 描述 |
| 面向服务设计范式（范型） | 是达成面向服务战略目标的一条途径，其代表八大面向服务设计原则的集合，其进一步增强了分布式系统方案逻辑不同部分之间的共同性。
架构设计标准、设计模式和最佳实践都能够支持设计范式的成功应用。 |
| 面向服务 | 是包含一系列特定设计原则的设计范式。 |
| 面向服务架构 | 确立一种架构模型，其旨在通过将服务定位为表达方案逻辑的主要途径以支持与面向服务计算相关的战略目标的实现。 |
| 面向服务计算 | 代表新一代分布式计算平台 |
| SOA技术架构 | 服务的基础物理设计 |
SOA技术进入主流开发行列，其经历了十几年的天花乱坠的宣传，逐步形成系统的理论体系、成熟的设计方法和经验化工程流程。
随着汽车行业数字化、智能化和网联化时代的到来，汽车技术和IT技术迎来大融合。其中，车辆作为物联网的终端，其软件架构也需要与主流的物联网架构具有对等架构模型，构建以车辆为中心的车云一体架构，为用户提供个性化服务生态。因此，SOA技术也成为汽车行业技术人员关注的焦点。
SOA是一个泛化的、系统的和复杂软件工程设计思想和方法，业界对其至今没有统一的学术定义。如何提高对SOA理论体系的认知，加快SOA的文化转播，促进SOA在企业落地，在项目中技术实施，是汽车行业急切关心的话题。
SOA的实践方式是“知行合一”。这里我们首先从汽车行业发展的视角解读和探索“SOA声明”，以方便车企从业人员正确掌握SOA开发理念，减少SOA技术的实施风险。
我们遵循以下原则：
– 尊重组织的社会和权力结构。
– 认识到SOA最终需要在许多层面上进行变革。
– SOA采用的范围可以不同。保持努力可控，并在有意义界限内。
– 产品和标准本身不会给你SOA，也不会为你提供面向服务范式。
– SOA可以通过各种技术和标准来实现。
– 根据行业、事实和社区标准建立统一的企业标准和政策。
– 在外部追求一致性，同时允许内部的多样性。
– 通过与业务和技术利益相关者的协作来识别服务。
– 通过考虑当前和未来的使用范围将服务使用最大化。
– 验证服务是否满足业务需求和目标。
– 发展服务及其组织响应实际使用。
– 分离以不同速率变化的系统的不同方面。
– 减少隐式依赖并发布所有外部依赖关系，以增强稳健性并减少变更带来的影响。
– 在每个抽象层次上，围绕一个内聚和可管理的功能单元组织每个服务。
– 在外部追求一致性，同时允许内部的多样性
思想解读：
联合可以定义为一组不同实体的统一。虽然每个实体可以在内部独立管理，但都要遵守一个共同的统一战线。
面向服务架构的基本部分是联合端点层的引入，该端点层以统一的方式发布表达给定域内各个服务的一组端点，来抽象服务实现细节。实现这一点通常涉及基于行业和设计标准的组合实现统一。这种跨服务统一的一致性是实现内在互操作性的关键，因为它代表了标准化服务锲约设计原则的主要目的和责任。
联合端点层还有助于增加探索供应商多样化选项的机会。例如，一个服务可能需要建立在另一个完全不同的平台上。只要这些服务保持兼容的端点，其各自可以保持独立治理。这不仅突出表明服务可以通过不同的实现技术(如EJB、.NET、SOAP、.JAVA、REST等)构建，还强调可以根据需要一起使用不同的中间平台和技术。
请注意，这种类型的多样性与成本价格关系密切。这个指导原则本身并不主张多元化，只是建议我们在合理的情况下允许多元化，以便利用“最佳”技术和平台来最大程度地实现业务需求。
行业解读：
车企在采用面向服务时，应坚持标准化服务锲约设计原则，以提高企业内外部IT资源的互操作性。基于行业标准和设计标准，通过服务抽象原则，为服务发布一个公共接口，即服务契约。基于服务锲约，服务可被消费者发现和调用。基于服务契约，给定应用区域可以建立联合端点层，以便于服务资源的统一管理和使用。基于服务锲约，服务的功能逻辑实现可以多样化，服务的实现平台或供应商也可以多样化，使得业务的创新更有活力。
车端将一个功能逻辑用接口元模型(Field/Event/Notification/Method）的方式封装来表达为一个服务端点，在分布式系统中软件程序是不具备互操作性的，企业长期战略价值是得不到体现的。
– 通过与业务和技术利益相关者的协作来识别服务
思想解读：
为了使技术解决方案成为业务驱动，该技术必须与业务同步。因此面向服务计算的另一个目标是通过应用面向服务来调整技术和业务。最初实现技术和业务对接的阶段，即通常在实际服务开发和交付之前进行服务分析和建模的过程。
开展面向服务分析的关键因素是让业务和技术专家携手合作、识别和定义候选服务。例如，业务专家可以帮助准确地定义与以业务为中心的服务相关的功能上下文，而技术专家可以提供实际输入，以确保概念性服务的粒度和定义在最终实现环境中保持真实性。
行业解读：
车企在采用面向服务时，必须保持业务和技术同步（因企业战略目标或企业长期发展愿景需要）。在实际服务开发和交付之前，必须进行服务分析和建模的过程，对于车端服务这点也同等重要。但在实现、部署和运行阶段也需要考虑兼容车端原有的开发方法和需求（如：V模型开发流程）。
– 通过考虑当前和未来的使用范围将服务使用最大化。；
思想解读：
给定SOA项目的范围可能在企业范围内，或者可能局限于企业的域。无论范围大小，首先创建一个预定义的边界以涵盖在开发之前需要进行概念建模的服务目录。通过对多个服务进行建模，我们基本上创建了最终将要构建的服务蓝图。尝试识别和定义一个有不同解决方案共性的服务时，此联系至关重要。
有各种方法和途径可用于执行面向服务的分析阶段。然而，所有这些方法的共同点是要规范化服务的功能边界以避免冗余。即使这样，正常化的服务也不一定能够实现高可重用的服务。其他因素发挥作用，例如服务颗粒度、自治性、状态管理、可扩展性、可组合性以及服务逻辑足够通用的程度，这样服务才能够被有效重用。
在业务和技术专长的指导下，这些类型的考虑因素提供了定义服务的机会，以捕捉当前的业务需求，同时拥有适应未来变化的灵活性。
行业解读：
车企在采用面向服务时，在预定义的边界内（域目录），对服务进行建模分析，以识别共享服务，避免服务的冗余开发，逐步构建车企自己的服务蓝图（可复用、统一标准和统一治理的IT资源、符合逻辑集中化原则），以应对未来车辆业务或功能灵活拓展的需求。
仅仅简单粗暴地将功能逻辑拆分与转化为所为的“服务”（没有满足基于服务设计原则要求的特性，如服务自治、服务契约、服务无状态、服务可组合等），最终是达成不了采用SOA的战略目标和战略价值。
– 验证服务是否满足业务需求和目标
思想解读：
与任何事务一样，服务可能被误用。增加和管理服务文件时，需要验证和衡量其在业务需求方面的使用性和有效性。现代工具提供了监控服务使用的各种手段，但也需要考虑无形资产，以确保服务不仅是因为可用而被使用，而要验证它们是真正能够满足业务需求并满足期望的。
对于承担多个依赖关系的共享服务尤其如此。共享服务不仅需要足够的基础设施，以保证所有重用解决方案的可扩展性和可靠性，还需要非常小心设计和扩展，以确保其功能上下文不会发生变化。
行业解读：
服务是一定范围统一标准和统一治理的软件程序，是企业无形的IT资源。其主要服务于企业业务拓展的需要，需要仔细设计，确保其可靠性、可组合性和可扩展性。
可扩展性是重要考量的一个特征，可以减少定制集成的成本，这个是服务设计过程尤其要关注的一个设计目标。
– 发展服务及其组织响应实际使用
思想解读：
这一指导原则直接关系到“追求最初完善的进化精神”价值观，以及保持业务和技术一致的总体目标。
我们永远不会期望依赖猜测来完成以下事情：确定服务粒度、服务需要执行的功能范围，以及服务需要如何组织到组合中。根据我们能够初步执行的任何分析程度，给定的服务将被分配一个已定义的功能上下文，并且将包含一个或多个可能涉及一个或多个服务组合的功能能力。
随着显示世界业务需求和环境的变化，服务可能需要扩充、扩展和重构，甚至可能被更换。面向服务的设计原则在服务架构中构建了本地的灵活性。这样服务作为软件程序就具有弹性，并能够适应变化，并且能够根据现实世界的使用进行变更。
行业解读：
车企在采用面向服务时，需要根据面向服务设计原则在服务构架中构建本地的灵活性，使业务与技术一致和同步。
同时，技术可以驱动业务发展的需求，为业务创新或车辆应用创新提供最佳实践环境。
– 分离以不同速率变化的系统的不同方面
思想解读：
变更可能会对现有使用产生重大影响，也会使单体和基于竖井的系统变得僵硬。这就是为什么通常更容易创建新的基于竖井的应用程序，而不是增加或扩展现有应用程序。
分离关注点理论背后理由是，当大问题分解成一组较小的问题或疑虑时，可以更有效地解决更大的问题。在应用面向服务来分离关注点时，我们构建了相应的解决方案逻辑单元来解决单一的问题，从而允许我们聚合单位来解决更大的问题，除了给我们机会将它们按顺序聚合成不同的配置以解决其他问题。
除了促进服务可重用性之外，这种方法引入了许多抽象层次，可帮助屏蔽服务组合系统免受变革的影响。这种抽象形式可以在不同层面上存在。例如，如果需要替换由一个服务封装的传统资源，只要服务能够保留其原始端点和功能行为，就可以减轻该变化的影响。
另一个例子是不可知逻辑与非不可知逻辑的分离。前一种类型的逻辑具有很高的重用潜力，如果他是多用途并且不太可能改变的。另一方面，非不可知逻辑通常代表父业务流程逻辑的单一目的部分，这些逻辑通常更易变。将这些各自的逻辑类型分为不同的服务层，进一步引入了在保护服务时能够实现服务可重用性的抽象，并且利用它们的任何解决方案，避免变更带来的影响。
行业解读：
车企在采用面向服务时，往往基于服务模型对架构进行分层处理，其主要有以下三个方面的考虑，以减轻企业IT负担。第一是软件程序的分层复用，不可知逻辑具有可重用性和可组合性，提高软件利用率。第二是业务的灵活性，非不可知逻辑本质是服务能力组合控制器，主要实现业务流程级的功能，单独分层便于业务的灵活调整。第三是软件的科学管理，将生命周期不同的软件程序分离，便于实现软件利用的最大收益，减少软件开发、使用和维护成本。
– 减少隐式依赖性并发布所有外部依赖关系，以增强稳健性并减少变更带来的影响
思想解读：
这一指导原则体现了服务松耦合设计原则的目的。服务架构如何内构、服务如何关联消费它们（可以包括其他服务）的程序，这一切都归结于对服务架构一部分单独移动部件的依赖。
抽象层通过将变化的影响定位到受控区域来帮助缓解进化变化。例如，在服务架构中，可以使用服务外观来抽象实现的部分，以便最小化实现依赖关系的范围。
另一方面，发布的技术服务契约需要揭露服务消费者必须形成的依赖关系，以便与服务进行交互。根据服务抽象原则，当变化确实发生时，减少可能影响技术契约的内部依赖关系会将这些更改对服务消费者的影响扩散减至最小。
行业解读：
车企在采用面向服务时，需要重视服务契约的设计。服务契约可以作为软件程序协同开发的桥梁，减少企业内外部团队交流的成本。服务契约也可以作为服务和外部消费者或其他服务交互的唯一合规的、公开发布接口，是与服务外部唯一有依存关系的服务部件。
服务契约包括功能、数据类型、端点定义、消息和可用与否等信息。不仅仅是我们传统软件程序中的函数API（应用程序接口）。服务合约的版本化管理技术可进一步帮助减少服务变更带来的影响。
– 在每个抽象层上，围绕一个内聚和可管理的功能单元组织每个服务
思想解读：
每个服务需要一个定义明确的功能上下文，用于确定服务功能边界内属于和不属于该上下文的逻辑。确定这些功能服务边界的范围和粒度是服务交付生命周期中最重要的职责之一。
具有粗糙功能粒度的服务可能不太灵活、有效，特别是预期可重用的。另一方面，过度细粒度的服务可能会对基础设施大打折扣，因为这些服务组合需要由组成成员的增加量组成。
确定功能范围和粒度的正确平衡需要业务和技术专业知识的结合，并进一步要求理解给定边界内的服务如何相互关联。
行业解读：
车企在采用面向服务时，需要重视服务颗粒度（功能边界）的设计。服务的颗粒度太大影响服务的复用性和业务的灵活性。服务的颗粒度太小影响服务的性能，会对扩大对运算平台资源和通讯资源的占用。
– 指导原则总结
本声明中描述的大部分指导原则有助于做出这一决定，将每项服务定位为能够将IT企业推向目标状态的IT资产，从而实现面向服务计算的战略优势。
然而最终，正是现实世界商业价值的实现才描述了从概念到交付、到重复使用，还描述了任何面向服务功能单元的演进路径。
以上，对企业采用面向服务给出的指导原则。其指出采用面向服务过程中，需要考虑加强标准化服务合约的设计，以增强服务的互操作性，减少服务的外部依赖。需要仔细服务分析和建模过程，以业务为关键输入和驱动，以识别服务，实现服务共享化。需要考虑服务的可扩性和可组合特性，以满足业务变更的灵活性和个体需求的适应性。同时，也应注意不同类型软件程序的生命周期管理，提高软件使用率，减少软件投入成本。
[1] http://www.soa-manifesto.org
[2] 《SOA Principle of Service Design》[USA] Thomas
评论0