今天看SOA时想到的

最新推荐文章于 2025-12-25 22:08:26 发布
最新推荐文章于 2025-12-25 22:08:26 发布 · 176 阅读 · 0
文章标签：

#SOA #Spring #Hibernate #Struts #设计模式

软件开发得本质是什么？

 

赚钱！

 

如何更快更好更长久得赚钱？

 

抓紧老业务(客户/项目)，开拓新业务，开源节流！

 

如何开源节流？

 

软件能够做到可复用/可维护/可扩展即可接生成本。

 

如何达到这个目的？

 

松耦合...


如何达到松耦合？

 

设计模式

分层

Spring

Hibernate

Struts

...

SOA

...

 

忽悠

SOA 开发基础 (下）
拖拉机日记
05-15 2466
上篇中从我的理解向大家介绍了“什么是SOA”，下篇还是继续原本的打算，梳理一下做SOA开发(本篇指的是智能座舱中SOA开发)需要具备的领域知识体系。 今天要做的梳理，没有思维导图，没有PDF，没有表格，是结合了我的实际经历和体会，总结得出的一些基础知识点，这是现阶段的这个我所了解的所认为的，随着时间的流逝，我又会经历更多一些，现在梳理的可能也会跟着改变一些。这种极其个性化的梳理，对我，是梳理(其实，写这篇比想象中艰辛，要不是前面给自己埋下了坑，都想放弃了~)，对你，看看便好，就当是听我絮叨絮叨，侃侃大山，
SOA 开发基础 (上）
拖拉机日记
04-26 3243
从去年开始(可能更早)，SOA的概念在汽车软件行业逐渐蔓延开来，很多公众号都发过讲汽车SOA的文章，很多车厂都要开始(或者已经在)搞SOA。但我觉得吧，在开搞新技术之前，是不是先花点时间弄明白这个技术到底是什么，它解决的是什么样的问题，然后再谈架构，再谈开发，很多时候我们连问题是什么都没整明白，就急着去做解决方案，最后的结果只能是一地鸡毛。对个人来说，要搞SOA开发，需要夯实哪些基础知识，看了很多SOA文章，却很少有人梳理这些，这段时间我陆续思考了一些，尽管可能不全面(更偏向SOC开发涉及的技术点)，但仍然
SOA面试题
世界属于三体
07-08 1618
原文：https://blog.youkuaiyun.com/kingmax54212008/article/details/49672943 SOA代表了面向服务的架构。如果你正在准备采取SOA，以下SOA的面试问题和答案可能对你非常有用。基本上，这些SOA的面试题涵盖了整个SOA。涉及SOA的服务特点和原理，服务，合同，地址和绑定的松耦合，SOA对于业务和IT的主要优点，服务与组件的差别，SOA的业务需求...
微服务与SOA的关系
rs勿忘初心的博客
02-08 847
一、SOA 和微服务对比 开门见山，直接给出部分维度下SOA 和微服务的对比情况： 接下来，详细从不同的对比维度说下SOA和微服务的特点： 1、服务粒度 整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个 SOA 架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务。 2、服务通信 SOA 采用了 ESB 作为服务间通信的
SOA VS 微服务
xinyuan的专栏
01-16 336
微服务是近几年非常火热的架构设计理念，大部分人认为是 Martin Fowler提出了微服务概念，但事实上微服务概念的历史要早得多，也不是 Martin Fowler创造出来的， Martin Fowler只是将微服务进行了系统的阐述。不过不能否认 Martin Fowler在推动微服务火热起来的作用，微服务能火， Martin Fowler功不可没。 参考维基百科英文版，我们简单梳理一下微服务的历史： 2005年：Dr. PeterRodgers在Web ServicesEdge大会上..
湘潭大学软件工程专业选修 SOA 期末考试复习（二）
夜空像是一片紫水潭，星星是些不动的大亮点，夜风是些浅蓝色的流线，云端传来喧嚣的声音。
11-07 1417
课后习题整理，感觉重点是选填。
【微服务】什么是SOA服务架构？
锦瑟年华,逐梦之人
02-20 1493
SOA SOA是Service Oriented Architecture的缩写，面向服务架构。Bezos（亚马逊CEO）将Amazon的软件架构完全转换为SOA，它是如此关键，从某种程度上改变了亚马逊 Amazon 的命运。 思想 SOA的精髓是严格的松散耦合，不允许直接访问其它服务的数据，大家按照一个契约或标准（service interface）来进行交流。 百科解释: 面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接
微服务与SOA以及服务间通讯协议
微服务技术栈
07-24 1822
说到微服务，就一定会想到微服务、分布式、集群、SOA、SOAP、restful、Http、RPC等相关概念，而这些概念都一些界限都非常的模式，很难理清楚确切的概念，本篇主要是介绍我对微服务中常遇到的一些问题的理解，很多东西也是查看了很多书籍之后才有一个模糊的概念。 分布式与集群 首先说是分布式与集群的概念，关于分布式比较官方的术语就是一组不同且有相互关联的组件分布在网络计算机上，并且仅仅通过消息传递来通信并协调行动。而集群则是将同一种组件分布在网络计算机上。它们之间的区别在于是否是同一组件（服务）的部署
简单聊聊SOA和微服务
zhaoguowei的博客
02-27 198
简单聊聊SOA和微服务 前两天和一个朋友聊天，他向我咨询如何从零开始构建一个健壮、强大的软件系统，聊着聊着他忽然问我，「听大家都在说微服务（下文中有的地方会使用MSA），还有人会提到SOA，那么他们的区别到底在哪里？」。我想了想，一时也列不出来一个详细的列表，只能跟他讲说其实他们在概念上是相似的。 关于软件系统的架构设计，是一个太多人喜欢讨论的问题，尤其是对软件开发不了解的人士来说，总是被各种各...
springBoot业务组件化开发（SOA ）
weixin_44213308的博客
12-15 3382
1、背景 首先，谈一谈什么是“springBoot业务组件化开发”，最近一直在开发一直面临这一个问题，就是相同的业务场景场景在一个项目中使用了，又需要再另外一个项目中复用，一遍又一遍的复制代码，然后想将该业务的代码在不同的项目中维护起来真的很难。 最开始想用微服务的方式来解决这个问题，但是觉得一套完整的微服务太重，而且目前微服务还处于振荡期（去年的微服务解决方案，今年国内直接都换成了阿里的技术解决方案），此外很多时候我们接私活，就是个单体的springboot项目，用不上微服务这种级别的项目，所以想来想
适合中小企业的SOA
03-04
在花费了很多时间处理企业IT的复杂性之后，我们应该想到那些小公司也有他们的IT需求。毕竟，每一个公司都有桌面电脑、网络和数量庞大的内部硬件和软件，以及网站和相关外部IT工作。尽管中小企业的IT需求很宽泛，但是...
0-3论软件设计模式及其应用、2016-已写（观察者通知，命令-控制指令，适配器-兼容，工厂-多种数据库）
qianshanxue11的博客
12-25 567
最重要的是，这些模式都是一些经过反复使用的成熟设计方案，符合面向对象中设计规范，比如：面向接口编程、里氏替换原则、单一职责原则、依赖倒转等设计原则，最大限度的提高软件的标准化，为日后的系统维护打下了很好的基础。这方面，我们还缺少相关的经验。常见的行为型模式有解释器模式，终结者模式，策略模式，备忘录模式，命令模式，职责链模式，中介者模式等11种模式。创建型模式，主要负责对象的创建工作，程序在确定需要创建对象时，可以获得更大的灵活性，常见的创建型设计模式有单例模式，工厂方法，原型，抽象工厂，建造者模式。
设计模式：命令模式
技术分析
12-23 676
命令模式是一种行为型设计模式，将请求封装为独立对象，实现发送者和执行者的解耦。其核心角色包括抽象命令、具体命令、调用者和接收者。典型应用场景如订单操作，通过命令对象绑定接收者和参数，调用者只需触发执行而无需了解具体实现。该模式支持扩展特性如命令撤销/重做、命令队列和宏命令组合。与策略模式不同，命令模式聚焦请求封装和解耦，而非算法切换。优点在于良好的解耦性和扩展性，但可能增加系统复杂度。适用于需要支持请求队列化、撤销或批量执行的场景，如Spring MVC框架中的请求处理机制。
c++ 语言教程——17面向对象设计模式（六）
mwl0223的博客
12-25 249
本文介绍了三种行为型设计模式：访问者模式、中介者模式和解释器模式。访问者模式通过分离数据结构与操作，支持在不修改元素类的情况下添加新操作，适用于操作频繁变化的场景，但会破坏封装性。中介者模式通过引入中介对象来协调多个对象间的交互，降低耦合度，适用于需要集中管理复杂交互的系统。文章通过C++代码示例分别展示了访问者模式在商品计价场景的应用，以及中介者模式在聊天室系统中的实现，分析了各自的优缺点和适用场景。
适配器模式
最新发布
lsx202406的博客
12-25 133
适配器模式是一种常用的设计模式，它可以解决接口不兼容的问题，提高类的复用性。在实际开发中，我们需要根据具体场景选择合适的设计模式，以达到最佳的设计效果。
设计模式-工厂方法模式
weixin_46515691的博客
12-22 427
工厂方法模式（Factory Method Pattern）是一种创建型设计模式。它在简单工厂模式的基础上进行了扩展，将对象的创建逻辑进一步抽象化，使得代码更具灵活性、可维护性和可扩展性。该模式旨在将对象的创建和使用分离，通过引入抽象工厂和具体工厂，使得系统在创建对象时更具灵活性和可扩展性。它是对简单工厂模式的进一步抽象和扩展，解决了简单工厂模式在产品种类增加时，工厂类逻辑过于复杂的问题。
java设计模式 - 工厂方法模式
qq_24428851的博客
12-22 435
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。著作权归作者所有,转载或内容合作请联系作者。
智能体（Agent）架构设计模式：基于实际项目的模块拆解
书山有路勤为径，学海无涯苦作舟。
12-24 825
本文探讨了智能体（Agent）架构的设计模式，基于金融分析等实际项目经验，深入拆解了智能体的核心模块和工程化路径。文章指出，智能体正从简单的"输入-输出"模式转变为具有"目标-规划-执行-反思"完整循环的自治系统，并面临可靠性、可控性等六大挑战。通过金融分析案例，详细解析了感知与理解、规划与决策等五大核心模块的设计要点，包括分层意图识别、弹性计划生成等关键技术，为构建生产级智能体系统提供了实用框架。
Head First设计模式（十三） 设计原则 现实世界中的模式
zyl042的博客
12-22 446
描述对象之间的关系，而且对象模式主要通过组合定义。对象模式中的关系通常在运行时创建，更加动态和有弹性。牵涉到对象实例化，这类模式都提供一种将客户从需要实例化的对象中解耦的方式。：描述业务，顾客和数据之间的交互，可以应用于如何高效决策并沟通决策等问题。就是你所追求的东西：一个通用的设计，所有人都可以用来解决目标和约束集。指在此上下文中你想要达到的目标，但也要考虑该上下文中发生的任何约束。类模式中的关系是在编译时建立的。：用来创建生气勃勃的建筑，城镇和城市的架构。：是创建系统级架构的模式。
微服务和SOA架构 使用java的开发框架开发
09-30
<think>嗯，用户现在明确想了解Java开发框架在SOA和微服务架构中的具体实现方法。看来ta是个技术决策者或架构师，正在为系统选型做调研。之前讨论过架构理论，现在需要落地到Java技术栈，这个转折很合理——理论懂了，自然要找工具实现。 用户特意强调要参考上次的架构对比，说明ta需要技术方案能体现SOA和微服务的关键差异点。比如数据库设计，上次提到微服务必须独立数据库，那么Java框架如何支持？Spring Boot的分散配置就比传统SOA框架灵活得多。 SOA方面，Java生态其实有明确的分层： - 底层协议：老牌框架多用WebService+SOAP，比如Apache CXF配XML简直噩梦 - 通信层：ESB方案中Apache ServiceMix这类基于OSGi的容器太重 - 服务治理：JBoss ESB的监控功能还行，但和云原生脱节 微服务框架就活跃多了： - Spring Cloud Alibaba全家桶最实用，从Nacos注册中心到Sentinel熔断全覆盖 - Quarkus这种新框架对K8s亲和力强，编译成native镜像启动才0.1秒 - 难点在事务管理：Seata的AT模式解决分布式事务，但需要改造SQL 用户可能没明说的痛点其实是遗留系统改造。比如银行核心系统用WebLogic部署SOA，要逐步拆微服务。这时Spring Cloud的Sidecar方案能让PHP服务接入Java体系，比硬迁移风险小。 另外ta提到“开发方法”，我得多给些模式对比： - 契约优先开发：SOA用WSDL生成代码，微服务用OpenAPI 3.0 - 配置管理：Archaius动态配置 vs SOA的静态JNDI绑定 - 最关键的——团队能力。微服务要求DevOps成熟度，否则分布式调试能逼疯人 最后决定用分层对比表，把Dubbo这类RPC框架也纳入SOA方案。突然想到用户如果是政府机构，可能要提国产化替代，比如用Tengine替代Nginx…… </think>以下是针对Java技术栈实现SOA与微服务架构的详细对比及框架选型方案，结合架构特性和实践要点： --- ### 一、SOA架构的Java实现方案 #### 核心框架与技术栈 | 组件 | 推荐框架 | 关键特性 | |---------------|----------------------------|---------------------------------------------| | **服务协议** | Apache CXF / JAX-WS | 支持SOAP/WSDL协议，集成Spring | | **ESB** | Apache ServiceMix / Mule ESB | 提供路由、转换、消息队列等企业级集成能力 | | **服务注册** | Apache ZooKeeper | 实现服务发现与配置管理（需二次开发） | | **事务管理** | JTA (Java Transaction API) | 支持分布式事务（如Atomikos） | ```java // SOAP服务示例(CXF) @WebService(endpointInterface = "com.example.OrderService") public class OrderServiceImpl implements OrderService { @Resource private InventoryService inventoryService; // 通过ESB调用 public String createOrder(Order order) { // 调用库存服务（依赖ESB路由） inventoryService.updateStock(order.getItems()); return "SOAP_ORDER_" + System.currentTimeMillis(); } } ``` #### 典型部署结构 ``` [前端应用] → [ESB] → [SOAP服务集群(WebLogic/Tomcat)] → [共享数据库] ``` > **适用场景**：银行核心系统（如中国工商银行的ESB集成架构）、电信计费系统[^1] --- ### 二、微服务架构的Java实现方案 #### 核心框架与技术栈 | 组件 | 推荐框架 | 关键特性 | |-----------------|------------------------------------------|---------------------------------------------------------| | **开发框架** | Spring Boot | 快速启动、自动配置（starter机制） | | **服务注册** | Netflix Eureka / Nacos / Consul | 动态服务发现与健康监测 | | **API网关** | Spring Cloud Gateway / Zuul | 路由、限流、熔断（集成Hystrix） | | **配置中心** | Spring Cloud Config / Apollo | 分布式配置管理 | | **分布式事务** | Seata / Saga模式 | 柔性事务解决方案（TCC模式） | | **容器化** | Docker + Kubernetes | 实现CI/CD和弹性伸缩 | ```java // Spring Cloud微服务示例 @RestController public class PaymentController { @Autowired private OrderServiceFeignClient orderClient; // Feign声明式HTTP调用 @PostMapping("/pay") @HystrixCommand(fallbackMethod = "processPaymentFallback") // 熔断保护 public PaymentResult pay(@RequestBody PaymentRequest request) { // 调用订单服务（直接HTTP通信） Order order = orderClient.getOrder(request.getOrderId()); return paymentService.process(order); } } ``` #### 基础设施依赖 ```mermaid graph LR A[API Gateway] --> B[订单服务] A --> C[支付服务] B --> D((Eureka注册中心)) C --> D D --> E[Config Server] ``` > **适用场景**：电商系统（如阿里双11架构）、社交平台实时服务[^2] --- ### 三、关键差异的Java实现对比 | **能力维度** | **SOA实现方案** | **微服务实现方案** | |--------------------|-----------------------------------|----------------------------------------| | 服务通信 | CXF+SOAP over HTTP | Spring Cloud OpenFeign (RESTful) | | 数据库访问 | JDBC连接共享池 | 各服务独立DataSource + Flyway迁移 | | 部署单元 | WAR包部署至应用服务器 | Docker镜像 + Kubernetes Pod | | 容错机制 | ESB死信队列 | Hystrix熔断器 + Sentinel流控 | | 配置管理 | properties文件静态配置 | Nacos动态配置推送 | | 性能开销 | SOAP XML解析损耗高 | HTTP/JSON序列化高效 | --- ### 四、混合架构实践建议 1. **遗留系统改造** - 使用 **Apache Camel** 将原有SOAP服务包装为REST接口 - 通过 **Sidecar模式** 将非Java服务接入Spring Cloud生态[^3] 2. **数据库解耦策略** ```java // 使用领域事件实现最终一致性 @Transactional public void placeOrder(Order order) { orderRepository.save(order); // 发布领域事件 eventPublisher.publishEvent(new OrderCreatedEvent(order.getId())); } ``` 3. **渐进式拆分路径** ```mermaid graph LR A[单体应用] --> B[SOA服务化] B --> C{识别高频变更模块} C -->|优先拆分| D[用户服务] C -->|次优先| E[商品服务] D --> F[独立微服务] ``` > **框架选型趋势**： > - SOA：Apache ServiceMix + CXF (传统企业) > - 微服务：Spring Boot + Spring Cloud Alibaba（云原生方案）[^2][^3] --- ### 五、风险规避指南 1. **分布式事务陷阱** - 避免XA两阶段提交（性能瓶颈） - 采用 **Seata AT模式**： ```sql /* 自动生成UNDO_LOG */ UPDATE product SET stock = stock - 10 WHERE id = 1001 ``` 2. **服务拆分过度** - 遵循 **“两周重构原则”** ：单个服务代码应在2周内可重写 - 使用 **DDD界限上下文** 定义服务边界 3. **监控盲区** - 集成 **Micrometer + Prometheus + Grafana** 实现全栈监控 - 关键指标： - 服务延迟：$P99 < 200ms$ - 错误率：$Error\_Rate = \frac{Failed\_Requests}{Total\_Requests} \times 100\% < 0.5\%$ ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值