服务化架构思考

原创

于 2025-05-15 14:47:46 发布 · 794 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#架构 #java #微服务

前言

架构分类

在软件设计领域，企业架构通常被划分为如下五种分类：

如何理解架构分类依据及其彼此之间的关系？业务是企业赖以生存之本，因此业务架构是基础、是灵魂，其他一切均是对业务架构的支撑；根据业务架构形成与之相应的产品架构和数据架构；最后通过技术架构落地实施。

应用架构用于对产品架构进行细分，通过应用集成形成产品。但是应用架构区别于产品架构的本质不应该只在粒度，更重要的是产品直接承接业务，按照业务问题域进行划分；而应用需要考虑通用能力沉淀和复用，为多个产品提供统一支撑。

业务架构 业务需求初期，将模糊的需求描述为清晰的问题域，主要包括业务规划、业务模块、业务流程。
产品架构 脱胎于业务架构（主要是业务流程和业务模块），关注的是功能的枚举和分类。
数据架构 从问题定义的视角，逻辑（流程）+ 数据是两个核心。业务架构分析流程的同时，另一个核心就是定义数据架构，结合流程和数据形成产品。在实践过程中数据架构的工作往往被置于产品架构或者应用架构内部，从全局视角看这是一种误区，数据作为企业宝贵资产，其架构的好坏直接影响企业竞争力，必须全局考量和设计。数据架构要解决两个关键问题 - 1.需要什么数据 2.如何存储数据。
应用架构 应用架构用于对产品架构进行细分，在产品架构的基础上进行更细粒度的问题拆解和职责划分，并抽取可复用模块沉淀形成基础能力。应用架构的最贴近落地实现。
技术架构 上述四个架构从问题定义视角出发，技术架构从问题解决的视角出发，关注的是技术选型、开发框架、开发语言等。

SOA

自19年底开始，我的工作内容就集中于供应链领域中台产品的建设，在建设过程中不可避免的一个关键词就是服务化，对此不同人会有不同的看法，个人对服务化的理解更倾向于SOA，因此通过本文谈一下对SOA的认知。

SOA作为一种架构风格，从架构分类的视角看更偏向于业务架构的一个思想体系，可以作为方法论指导我们从业务模型定义开始一直到整体的业务架构落地。SOA强调我们对业务本质的思考和设计，通过共创的方式（方式而非形式）对业务本质不断的追溯、抽象、总结、归纳、演绎，用于提升业务灵活性、加快业务创新、提升业务效率；不应该跳过业务架构将其当作一个应用架构或者技术架构的术语。往往在谈到服务化的时候，很多实践就会用技术框架（平台）来等价代换服务化的概念，追求将热点的技术框架（如serverless、codeless）在现有系统中的落地作为整个服务化建设的主旋律，这样的建设最终往往收效欠佳。原因就是技术框架的使用仅仅是术、是器，而服务化（SOA）的本质是道、是法。

软件架构在SOA提出之后尚未发生变革性的突破，很多架构思想如 EA分层架构、微服务架构、DDD架构 等，大多都是在SOA架构风格的基础上进行不同角度的演化迭代，因此本文在阐述SOA的过程多少会存在其他架构思想中的“影子”。

正文

What、Why、How三个视角看SOA。

1.What

术语

任何概念的定义，都有与之对应的术语。

业务行为 具备一定业务语义的原子行为抽象。
业务流程 实现特定业务价值（满足客户需求）的一些列业务行为的有机组合。
业务服务 提供增值价值的业务行为或业务流程（需要特别说明的是业务服务既可以是业务流程也可以是业务行为、甚至两者的组合）。具有明确业务功能定义和价值衡量标准（SLA）。
应用组件 按照一定的相关性结构化封装的应用功能（为方便理解，在不考虑分层的前提下，简化等价于业务服务）的一个集合。用以提升应用的一致性、灵活性，并实现重用。