一、SOA架构SOA:面向服务的架构，或基于服务的企业IT架构。SOA中的服务概念本质上是一种业务和技术完全分离并且可以自由组合的思想。达到了目前软件设计思想的最高水平。
增强现实导航软件应用于SOA框架，其提供的SOAP接口可以满足不同语言和平台的调用。采用了HTTP协议，这是一个跨平台的协议，所以对于Android和后台的交互来说无疑是一个更好的选择。
SOA有三个基本元素。只有这三个基本要素都满足了，这个应用才能称为SOA编程：(1)松耦合；(2)粒度粗；(3)位置和传输协议是透明的。
(1)松耦合是指相互依赖的程度，包括三个方面：1)服务之间的松耦合：不同服务的功能不应该相互依赖，它们是相对独立和完整的，即所谓的自包含；这样更好的管理各种数据。2)接口和实现之间的松耦合：J2EE或。NET只能通过WSDL调用WEB SERVICE的服务接口；3)业务组件和传输协议之间的松耦合：传输协议和位置的透明性。(2)粗粒度是指SOA中服务的接口要比面向对象编程的API大。这个问题用ATM的取款功能来说明。提现功能的实现实际上可能包括以下三个API:1: 1)身份验证：系统确认用户输入的卡号和密码是否正确；2)余额查询：账户是否有足够的取款金额；3)提现：只有满足以上两项，才会向用户支付现金。
ATM取款功能的三个API
作为SOA的业务接口，两个API 身份验证和余额查询无法发布给用户，因为它们太详细。如果用户要操作这两个界面，然后操作退出界面，这不符合用户的操作习惯。因此，系统只能给出一个服务接口退出那符合用户的操作习惯。它包含前两个API函数。
(3)位置和传输协议的透明性是SOA和面向组件编程最根本的区别。目前，EJB、WEB服务和JMS等服务组件的发布都是绑定到特定的应用服务器上的。如果服务组件的URL位置被修改，客户端程序也必须相应地修改，否则整个集成将无法工作。这是位置组件的不透明度。
所谓位置透明，就是不管服务组件的实际位置URL如何变化，客户端的调用程序的URL都不需要改变。传输协议透明是指无论服务组件的传输协议如何变化，客户端调用程序的传输协议都不需要改变。
二、SOA工作流SOA架构中有三个角色：(1)服务提供者：发布自己的服务，响应服务请求。(2)服务注册中心代理：注册已发布的web服务，对其进行分类，并提供搜索服务。(3)消费者服务请求者：使用服务中心找到所需的服务，然后使用该服务。
SOA的三个操作：(1)发布操作：为了使服务可访问，需要发布服务描述，以便服务消费者发现。(2)搜索操作：服务请求者通过查询服务注册中心找到符合其标准的服务来定位服务。(3)绑定操作：服务消费者检索到服务描述后，根据服务描述中的信息继续调用服务。
SOA的例子：石油企业中有许多不同的网站。进入每个网站都需要认证，不仅浪费时间还容易忘记密码。此外，网站维护人员需要为各种服务建立相应的用户认证和信息管理系统。分布在各个服务器上的用户数据不仅浪费了维护人员的时间，而且用户数据过于分散，不利于统计和管理。用户需求和管理要求促使用户统一，从而产生了unifier的认证。统一授权
我们可以看到使用SOA的优势：认证功能模块作为服务发布，其他软件可以通过UUDI找到服务，然后将服务与服务的实现绑定。
三、SOA架构SOA的层次。要设计SOA类型的架构，有必要了解SOA架构模型。我们可以不要想当然地认为我们可以简单地拆分系统。我们需要弄清楚SOA的架构模型是什么，以及每个块的用途，这样我们就可以在设计分析阶段输出的需求时正确划分职责。
如果把SOA的架构简单理解为多个子系统的集成，其实有点太简单了，并没有真正理解SOA的架构模型。按照SOA正确的方法论和目标模型，其实在实现架构的时候，SOA需要考虑服务的组合，不断重用已有的服务，这样才能一步一步的整合企业应用，快速实现业务迭代。事实上，这一部分是关于服务的分层。通过分层，服务按照使用类型分布，上层服务封装下层服务，下层服务负责原子操作，上层服务在业务上组合下层服务。
让让我们看看每一层的具体角色和主要职责。
1、应用服务(原子服务)
应用程序包括订单服务、仓库服务、销售服务和客户管理服务。这些服务直接对应不同的应用系统，直接服务于这些应用系统的原子操作。订单被直接原子地插入到订单中，没有任何跨其他服务的分支逻辑。仓库只关心自己的仓库逻辑。其他应用程序服务应该只负责自己的职责，停止调用其他服务。
应用程序位于用户界面和背景之间。在后台，我们可以把它想象成一个异构系统或者一个数据库。应用程序位于前端和后端之间，其作用类似于服务API，但SOA中的服务远不止这个应用程序服务。如果我们的SOA架构中只有一种类型的服务，就会增加我们系统的耦合度。因为你没有对系统的服务进行层级划分，你的业务功能会直接落在一个应用线上的服务里。继续读。
2、组合服务
服务组合是应用服务的组合。根据实际项目的规模，没有必要进行物理隔离。也可以在代码级别对其进行维护。毕竟物理拆分有严重的成本和代价，给系统的稳定性带来很多挑战。所以经验告诉我们必要的时候要分裂。"分布式系统设计的首要原则是尽量不被分布。"这是马丁。福勒大师说，现在我明白了，真的有同感。
组合将较低的应用程序服务组合在一起，并完成一个基本的业务操作。应用服务是最基本的原子操作。然而，在复杂的业务需求下，大多数业务功能需要跨越多条应用线来完成一个最外层的企业动作。提交订单可能需要经过很多应用线，比如订单管理、仓库、财务等等。因此，这里我们还需要一个业务服务，它可以在最外层安排组合服务。这种编排服务可以完全自动化，通过工作流引擎的组合自动化来完成，对企业应用的自动化进程具有重要意义。
3、业务服务(编排服务)
服务是最外层的服务，复合服务向下排列。服务位于顶层。当需要跨多个应用程序线的服务时，该服务被放入业务服务中。比如提交订单，先查库存，扣库存(冻结库存)，再下单，再通知财务部，再通知物流部等等。都是复杂的企业服务线。这个最外层的商业逻辑，如果你不层SOA然后把它放到最外层的业务服务中，你把它放到任何一个应用行都会把系统调用搞糊涂。所以问题是我们需要垂直划分层级。如果SOA的层次划分了，就不会有互相误用的情况。其实可以参考阿里的服务设计方法。(李志辉写的大型互联网架构与实践也谈到了服务的层级)
当业务逻辑在业务服务中执行时，它需要跨多个应用程序线来完成。这部分逻辑也叫责任。如果你不不要把它放在这个位置，它把它放在任何一个应用程序行都是不合适的，你放在哪个应用程序行会造成系统调用的混乱。实际上，这里的问题是我们可以不要用一个维度来设计SOA系统。原有服务具有组合性的特点，适当提升服务水平是有益的。但是，应用程序服务和组合服务可以在代码级别构建，而业务服务(也称为编排服务)需要进行物理隔离。毕竟考虑系统的复杂性和稳定性是值得的。物理隔离在故障排除问题、系统性能、稳定性等方面起到一定的作用。毕竟，业务服务意味着将多个应用程序线结合起来，这将使整个系统架构变得清晰。
四、基于SOA的重构SOA的实现，在大多数情况下，都是在重构现有系统之后考虑的。在企业发展初期，快速原型是首要目标，只有当系统出现瓶颈时才会考虑用SOA来解决。但在这个时候，有许多历史包袱可以解决不了。事实上，基于SOA的重构成本非常高，而且非常危险。对于一些复杂逻辑的现实，你无能为力。如果一切都可以通过重构这项技术来解决，那我们就太天真了。055-79000这本书讲的是代码级重构，后面是系统级重构。系统级重构没有太多成熟的方法论支持。尤其是现在，新技术层出不穷，各有各的优势。使用这些技术、方法论和流程来重构大型企业级系统是非常困难的，需要整个公司投入大量的人力和资源成本。回过头来看，其实前期适当考虑还是很有必要的，后期可以减少很多技术债。
在这里，我只总结我在分析和设计公司某个业务系统时，对基于SOA的重构的思考。重构是一个迭代的过程，它可以这不是一大步。有了很多脚手架的支持，系统会逐渐过渡到新的SOA架构。既然要实现SOA架构，正确地对迁移的业务逻辑进行分类是非常重要的，哪些业务逻辑应该放入商业服务，应该放入什么逻辑复合服务在代码层面，如何把基本操作变成应用服务在代码级别。
1、为将来的服务组合预留服务空间。
在系统拆分的时候，对当前的后端调用进行了适当的规划，分为两类，一类是应用服务，一类是组合服务，可以在代码层面进行抽象。重点是那些调用其他系统的地方，需要投入业务服务。这个逻辑很复杂，很难提取，需要适当结合数据登陆。有时，在本地删除一些数据可以提高系统的整体简洁性和稳定性，但是应该考虑数据的生命周期性质。
在迁移过程中，可能会并行开发一些新功能。既有需要放入新SOA服务的新逻辑，也有迁移的逻辑。这两个过程同时进行，其实是很痛苦的。同时尽量避免这样做，但现实根本不可能。正常情况下，它们都是一起并行进行的。如果这两个过程是同一个团队的责任，它实际上很好。毕竟我更了解这一块的代码和业务。
这个程序的目的是强调，在迁移当前系统时，我们应该考虑服务级别，而不仅仅是简单地移动代码。这个时候是重构代码的好机会。级别要分，读写要分开，还有商业服务应该着重考虑，跨多条应用程序线的逻辑应该交叉。
对了，还有很重要的一点，就是迁移的时候要考虑数据存储的迁移。光码层面的迁移只是第一步，第二步需要数据层面的迁移。当然，这两大步骤都要经过多次迭代才能完成，也是梳理业务和代码的好机会。
在对系统进行维护时，应该考虑服务层。如果目前没有业务服务逻辑，应该预留服务空间。至少，要明确服务层有这样的空间要预留。当其他应用线路需要与你交互时，可以顺利进入你的服务区域，而不是直接到达你的应用。
五、使用DDD GRASP进行分析和设计(防止主观判断导致错误假设)在设计一个系统的时候，最怕的就是责任出了问题，会让系统架构突然变得复杂，系统架构是一个很难改变或者可以的决策一点也没变。所以，我一直很重视这一块。有的时候，熟悉了业务，还是会犯职责上的错误。对于这一块，单纯的主观判断是不长远的，不可复制，不可传播，不可书写。
我赢了这里不介绍DDD，但我想在这里强调把握。DDD的应用可以帮助我们战略性地观察企业所处的领域。我仍然强烈主张DDD 在公司的实施。更不用说战术设计DDD的方法论，只是说它的战略设计方法论还是很有用的，可以让我们在头脑中建立战略模型。代码级别要不要实现，要看实际情况。而且，DDD很多好的想法都可以借鉴，包括领域通用语言。有了领域通用语言团队之间的沟通和交流，可以节省很多成本。对于新人来说，他们可以很快了解公司的一些一般业务，这实际上不同于词汇表。
如上所述，在划分责任时，很多人都是通过经验做出主观判断，没有其他客观证据。那么，有没有好的方法论或者模型来指导我们解决这类问题呢？其实是有的，因为这方面在国外已经很成熟了。
GRASP就是这样一套模式，可以帮助我们进行客观的设计职责。最后，有关于将这段数据放入哪个应用程序以及将这个逻辑放入哪个服务的说明，包括对象级的设计。我们可能都知道信息专家模型，但过去我们可能只在对象设计中使用过，没有在一个系统的层面上考虑。那因为我们可能还没有过去没有遇到过复杂的责任分配，只有出了问题，我们才能真正理解事情的质量。
DDD只有与把握相结合，才能在某个领域客观准确地分配职责，无论是在战略设计层面还是战术设计层面，这都是一个很好的平衡标准。不会因为技术人员的主观利益倾向而导致错误的责任分配决策，而这个错误的决策最终需要开发者来买单。
六、SOA分布式下的SOA数据一致性。传统的分布式系统和当代面向SOA的分布式系统之间存在一些差异。从概念上讲，SOA是以服务为中心的，既然是以服务为中心，就会有很多面向服务的设计原则。而传统的分布式系统没有服务的概念，也没有所谓的一切都是服务的原则。但是当代SOA的首要原则是以服务为中心，服务设计有很多服务设计原则。
SOA服务也根据其应用级别进行分类：业务服务、组合服务、应用服务、打包服务等。然后按照管理和运维的级别进行分类：控制服务、调度服务、监控服务等等。传统的分布式系统不会我没有这些。我们谈论的是当代SOA的分布式系统，所以我们强调以服务为中心和服务设计原则作为架构设计的指导要求。当代SOA是传统分布式系统的迭代进化，而不是一个时代的产物。SOA强调服务为第一原则，并被提升到另一个更高的层次。
在本节中，我们将讨论当代SOA分布式系统中的数据一致性问题。在SOA中，主要涉及两个层面，一个是服务层面，一个是数据持久化层面。根据一致性的基本要求，可以分为几个维度：读一致性、写一致性、会话一致性、最终一致性、实时一致性等。当然还有其他维度的一致性要求。
这里重点介绍在企业应用中实施SOA时遇到的一些棘手的数据一致性问题及解决方案，对于刚才提到的几个维度的一致性需求有重要的参考价值。
1、分布式事务(基于DTC的分布式事务)
很多项目，包括过去，还是倾向于用DTC来处理分布式事务。这种方案大多适合一般的企业级应用，对业务、流量、数据量的要求不是很高。它使用DTC很方便，如事务的自动传播、自动感知、自动回滚和提交，都由中央DTC管理。
因为中央DTC的统一协调，看似帮我们解决了很多需要考虑的问题，但也是整个平台的致命瓶颈。一旦DTC因为某个问题出错，而所有这样的错误都是系统级错误，那么很多问题我们就无能为力了。如果出了问题，整个应用平台可以不能完成任何跨服务的业务流程，这其实是非常危险的。你可以不能不控制系统的稳定性。
综上所述，DTC用于一般的小型业务应用，不建议用于中型业务应用。不是说这个东西不好，而是控制不了。
2、交易补偿(提供正向或反向操作，使数据在业务中保持一致)
世界级SOA专家写的书都提到了补偿完成数据不一致的操作。当我们编写一个服务方法A时，需要一个服务方法A1的补偿接口来完成服务A的补偿操作，然而在真实的业务情况下，很难实现如此美观灵活的设计。没有实践，就没有发言权。我们公司的技术团队已经实现了这个方案，但是并不理想。与技术本身和技术团队无关，而是我们的平台业务太复杂补偿已经做过的手术。
当然也要看你面对的项目的情况。量变导致质变。如果你所有的数量都上升，这补偿方案不切实际，而且很难补偿在数据层面。总之，这不是长远之计。
3、异步EDA(基于异步事件流的灵活分布式事务)
EDA缩写为事件驱动架构。多个系统通过传播事件。系统之间没有紧密耦合，同步调用操作是通过发出异步事件。
你可能会有一个疑问，异步操作，系统之间延迟长吗？实际上，它不是 .现在intranet上有很多成熟的消息中间件，延迟几乎是毫秒级的。至于跨机房，就看物理距离了。
异步操作有很多优点，所以我赢了不要浪费每个人是时候在这里重复它们了。利用EDA实现系统间松散的事务关系，需要对项目的质量进行控制，对系统的非功能需求、bug数量等可能影响业务运行中断的地方建立适当的机制，使这些问题尽快在线上线下得到解决。例如，可以实现一些敏捷方法，如单元测试和持续集成。
综上所述，同样的工具，看谁用。真正的工匠使用非常简单的工具雕刻艺术品，可以不要被超越。这就是匠人的情怀。最近对工匠的感受越来越深。我一直以为我是专业人士。这是不是偏离了一个大方向，冲进了一个小巷子？直到最近，我才意识到这其实是软件工匠。但这并不不代表你不喜欢。don’不要考虑全局。它它只是一种感觉和一种态度，它架构和代码也是如此。唐不要忽视那些看似微不足道的问题，用工匠精神去雕琢。
标签：服务SOA系统