SOA宣言和微服务特点

如果从概念层来看,我更喜欢把SOA归为企业架构的范畴,从企业架构出发把业务分解为不同业务域的服务,关注系统间的服务互联互通的规范,并不关心如何实现。也就是说在企业架构上使用SOA支撑业务,而在方案架构使用微服务架构来实现.

SOA 宣言

面向服务是一种规范行为的范式。面向服务架构(SOA)是一种应用于面向服务而形成的一种架构。

我们一直以来运用面向服务来帮助组织始终如一的交付可持续的业务价值, 以提高灵活性和成本效益来符合变化的业务需求。

在我们的工作中, 我们会作如下优先排序:

  1. 业务价值 高于 技术策略
  2. 战略目标 高于 特定项目的效益
  3. 内在互操作性 高于 定制的集成
  4. 共享的服务 高于 特定目标的实现
  5. 灵活性 高于 优化
  6. 不断演进的提炼 高于 在最开始追求完美

也就是说, 我们认为右边的要素有其价值,但我们更加重视左边要素的价值

 

SOA 指导原则

我们遵循如下原则:

  1. 尊重组织的社会和权力结构
  2. 认识到SOA最终需要在许多层面上做出改变
  3. 采用SOA的范围可以多种多样, 确保工作量可控并处于有意义的范围内
  4. 产品和标准本身既不会给你 SOA ,也不会为你应用面向服务的范式
  5. SOA 可以通过不同的技术和标准来实现
  6. 建立一套基于行业和社区标准的统一的企业标准和政策
  7. 追求外在的统一性,同时允许内在的多样性
  8. 通过与业务和技术的利益相关者协作来识别服务
  9. 考虑目前和未来的使用范围,从而最大限度的提高服务的用途
  10. 验证服务满足业务需求和目标
  11. 演进服务及其组织方式来应对实际的使用
  12. 分开一个系统中以不同速率变化的不同方面
  13. 减少隐含的依赖,并公布所有外部依赖, 以增强系统的健壮性, 减少依赖变化造成的影响
  14. 在抽象的没一个层次,围绕一个紧密结合和可管理的功能单位来组织每一个服务

微服务架构的特征

Martin Fowler 在他的文章中总结了Micro Service的特点:

  1. 围绕业务能力来组织
  2. 做产品而非做项目
  3. 智能终端加弱通道
  4. 去中心化治理
  5. 去中心化数据管理
  6. 基础设施自动化
  7. 为应对失败而设计
  8. 演进式设计

The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Leonid Felikson
October 2010
History of The SOA Manifesto
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
2
•The SOA Manifesto was published in October 2009
•The Annotated SOA Manifesto, Insights and Commentary about the SOA Manifesto, was published in November 2009
•By October 2010, the SOA Manifesto has been translated to 9 languages:
–Chinese, Dutch, French, German, Italian, Portuguese, Russian, Spanish and Tamil
•By October 2010, the Annotated SOA Manifesto has been translated to 5 languages:
–Dutch, French, German, Russian and Spanish
Semantics First
•What does the word “paradigm”mean:
–from Greek: παρ?δειγμα paradeigmameaning pattern
–from Greek: paradeiknunaimeaning to compare
–composite from para-and the verb deiknunai"to show"
–The Oxford English Dictionary defines paradigm as "a pattern or model, an exemplar“.
•“Paradigm” has been used in linguistics and science to describe distinct concepts.
•Paradigm is “the generally accepted perspective of a particular discipline at a given time”.
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
3
Service orientation is a paradigmthat frames what you do.
(The SOA Manifesto)
Semantics First, cont’d
•SOA is not type of technology, nor it is a software product
•SOA is a type of Architecture
•We can’t buy SOA like we buy a technology product or tool
•Goals of SOA are rather strategic, not tactical
•Applying service orientation as a consistent, systematic discipline
•All types of architecture are affected by service orientation: business, data, infrastructure, application, security, integration
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
4
Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
Semantics First, cont’d
•Service orientation is a method of achieving target state defined by set of sustainable, strategic business goals and benefits
•Modeling reality by designing and developing software as a service, by applying service orientation principles
•Delivering new business capabilities is easier (due to intrinsic service composability and interoperability) –> business agility
•Service reuse contributes into cost effectiveness
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
5
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agilityandcost effectiveness, in line with changing business needs.
Six Core Values of SO Prioritized
•Business drives, technology supports
•Impact on all phases of software life cycle
•Supported by all other SO values and principles
•Services model “horizontal” business capabilities and therefore are strategically positioned to be enterprise-scoped, not project-scoped
•Services are repeatable and shareable –> “multi-purpose”, cross-project solutions vs. “single-purpose”, “silo” legacy applications
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
6
Business value over technical strategy.Strategic goals over project-specific benefits.
Six Core Values of SO Prioritized, cont’d
•Interoperability is ability to exchange and use information
•Practicing service orientation leads to interoperability by design, not by customization
•Services exhibit encapsulation of “multi-purpose” business logic, therefore can be shared and reused –> cost effectiveness, agility
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
7
Intrinsic interoperability over custom integration.
Shared services over specific-purpose implementations.
Six Core Values of SO Prioritized, cont’d
•Optimization remains valuable (i.e. for performance reasons)
•Flexibility –> interoperability
•Flexibility includes ease of composability, therefore agility in delivering new business capabilities
•Business change is “norm”
•Services are designed and built to change
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
8
Flexibility over optimization.Evolutionary refinement over pursuit of initial perfection.
Fourteen Guiding Principles
•Gain executive management buy-in and support
•Hide technology language while talking to executive management
•Establish community-centric mindset
•Make SOA adoption as business-driven, not technology-driven
•SOA projects require new approach in funding models, project management, software development life cycle, etc.
•SOA impacts not so much technology architecture, but more business and data architectures
•SOA changes governance model and processes
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
9
Respect the social and power structure of the organization.Recognize that SOA ultimately demands change on many levels.
Fourteen Guiding Principles, cont’d
•Manage scope of SOA adoption
•Domain-centric vs. enterprise-centric approach
•SOA Governance is priority for any scope of SOA adoption
•See “big picture”, start from “small” steps
•We can’t buy SOA!
•SOA enabling products don’t warrant success of SOA approach!
10
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
Fourteen Guiding Principles, cont’d
•Service orientation is technology and vendor neutral paradigm
•Just like we can write code with different programming languages, we can realize SOA with variety of technologies
•Rely on industry standards and policies, but consider having your own
•Have principles and policies that work for stakeholders, not against them
•Ensure quality not quantity of standards and policies in use
11
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
SOA can be realized through a variety of technologies and standards.Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
Fourteen Guiding Principles, cont’d
•Unified, federated endpoint layer is based on standards used for presenting exposed interfaces
•Consistent application of industry standards ensures unity from end-user view
•Internally, variety of technologies and programming models and platforms can be used; stand-alone or working together
•SOA is not a technology-centric effort and shouldn’t be viewed as such
•Variety of stakeholders work together on SOA adoption program
•Not only does SOA require business-IT collaboration, but it helps to moderate it
12
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Pursue uniformity on the outside while allowing diversity on the inside.Identify services through collaboration with business and technology stakeholders.
Fourteen Guiding Principles, cont’d
•Service orientation promotes reuse
•Services are designed for change and expended reuse
•Services granularity impacts potential reuse
•Service usage and effectiveness at fulfilling business requirements need to be verified and measured
•Tools are required to measure fulfillment of business needs and expectations
13
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Maximize service usage by considering the current and future scope of utilization.Verify that services satisfy business requirements and goals.
Fourteen Guiding Principles, cont’d
•Services in production require continuous performance assessment and ongoing feedback of customer satisfaction
•Services are in constant evolvement process
•Services are resilient and adaptive to change in response to real world usage
•Service-oriented approach allows decomposition of large business problem to deal with smaller concerns
•Separation of agnostic and non-agnostic business logic allows design of numerous layers of abstraction and helps to shield service-comprised systems from the impacts of change.
•Therefore, with service orientation we achieve higher degree of change resilience.
14
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Evolve services and their organization in response to real use.Separate the different aspects of a system that change at different rates.
Fourteen Guiding Principles, cont’d
•Transparency of services helps to establish trust between providers and consumers of services
•Reducing internal dependencies makes integration easier
•Several service design patterns help to achieve greater degree of decoupling, i.e. service façade pattern
•Well-designed and well-defined functional context of the service leads to well-composed business capabilities
•Choose the best granularity for your services based on desired business context and functionality
15
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change. At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
Conclusion
•The SOA Manifesto’s defined service-oriented principles unify community, establish priorities and values, and provide pragmatic guidelines
•This document is a great step towards a common understanding of key success criteria for SOA as an important strategic element in today’s agile business environment
•It finds ways of clearly defining objectives and goals for a subject of such significant magnitude of complexity
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
16

原文地址:https://www.cnblogs.com/dadadechengzi/p/9517022.html

时间: 2024-07-30 09:40:50

SOA宣言和微服务特点的相关文章

SOA架构与微服务的区别异同

SOA架构介绍 按照英文维基百科定义:SOA(Service-Oriented-Architecture)是一种"软件"和"软件架构"的设计模式(或者叫设计原则).它是基于相互独立的软件片段要将自身的功能通过"服务"提供给其他应用 面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建

SOA 架构与微服务架构的区别

注重重用,微服务注重重写 SOA 的主要目的是为了企业各个系统更加容易地融合在一起. 微服务通常由重写一个模块开始.要把整个巨石型的应用重写是有很大的风险的,也不一定必要.我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始. 把它们一个一个剥离出来用敏捷地重写,可以尝试最新的技术和语言和框架,然后 单独布署.它通常不依赖其他服务.微服务中常用的 API Gateway 的模式主要目的也不是重用代码. 而是减少客户端和服务间的往来.API gateway 模式不等同与 Fac

Atitit.架构设计趋势 设计模式 ---微服务架构  soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

软件架构的演进:单体、垂直、SOA、微服务

软件架构演进 软件架构的发展经历了从单体结构.垂直架构.SOA架构到微服务架构的过程,以下为具体分类: 1.1.1      单体架构 特点: 1.所有的功能集成在一个项目工程中. 2.所有的功能打一个war包部署到服务器. 3.应用与数据库分开部署. 4.通过部署应用集群和数据库集群来提高系统的性能. 优点: 1.项目架构简单,前期开发成本低,周期短,小型项目的首选. 缺点: 1.全部功能集成在一个工程中,对于大型项目不易开发.扩展及维护. 2.系统性能扩展只能通过扩展集群结点,成本高.有瓶颈

微服务、SOA、ESB比较

很多时候会听到微服务.SOA.ESB之间有着联系也有着区别,有时候了解了一下,过段时间有混肴模糊了今天看了一篇文章写的很好,特地记录一下. 原文地址:https://mp.weixin.qq.com/s/fCsVP5pO2vJX3DlMb-RdrA 一.SOA架构解析 SOA 全称是: Service Oriented Architecture,中文释义为 “面向服务的架构”它是一种设计理念,其中包含多个服务, 服务之间通过相互依赖最终提供一系列完整的功能.各个服务通常以独立的形式部署运行,服务

程序员修神之路--为什么有了SOA,我们还用微服务?

菜菜哥,我最近需要做一个项目,老大让我用微服务的方式来做 那挺好呀,微服务现在的确很流行 我以前在别的公司都是以SOA的方式,SOA也是面向服务的方式呀 的确,微服务和SOA有相同之处 面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互.它是一种设计方法,其中包

微服务与SOA:有什么区别?

在优锐课的java架构分享学习中,讨论了关于微服务是新的SOA吗? 人们还在谈论SOA吗? 让我们研究一下整体结构与这两种更新的体系结构之间的区别. 在"什么是微服务"中,了解到具有分布式架构的SOA和微服务比单片架构具有明显的优势. 在本博客中,我将解释基于分层的架构,并告诉你微服务和SOA架构之间的区别. 在深入研究微服务和SOA之间的差异之前,让我告诉你单片式架构,SOA和微服务之间的基本差异: 用外行的术语来说,一个整体类似于一个大容器,其中应用程序的所有软件组件都组装在一起并

深解微服务架构:从过去,到未来|架构(2015-07-15)

随着用户需求个性化.产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性.扩展性.伸缩性以及高可用性发展的必然方向.同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障. 微服务的诞生   微服务架构(Microservice Architect)是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调.互相配合,为用户提供最终价值.每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟