发表于： 2019-10-18 23:34:44
1 808
一、今天完成的事情：
1.SOA
SOA，面向服务的体系结构（service-oriented architecture）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
面向服务是一个解耦的过程，松耦合降低了服务之间的依赖，也意味着服务一个服务出现故障的时候不容易引起连锁反应，也能更好的控制服务与服务之间的关系与优先级。
面向服务以服务为出发点，组织和协调相关的对象来提供目标服务，对外提供必要的参数输入接口，将服务的结果作为输出，而“服务”本身的计算过程和组织则被封装在一起，对用户透明。其实面向服务也是以功能（服务）为中心，但其强调的是功能的整体性，封装性、自包性，而不是过程性和协作性，整体性指的是服务对外是作为一整体来体现的；封装性指的是服务完成的计算和处理过程、自有属性都不直接暴露给外部，除了通过公共的服务接口进行交互外，用户无法也不用知道内部的具体组织和协调的；自包性指的是服务的完成不依赖于服务的调用方，服务系统的本身就可以完成服务所需的功能；因此面向服务在程序组织上处于更高的层次，是一种粗粒度的组织方法。
2.SCA
SCA，(Service Component Architecture) 是一个开发SOA(Service-Oriented Architecture)面向服务应用的简单模型规范，它描述用于使用SOA构建应用程序和系统的模型。它可简化使用SOA进行的应用程序开发和实现工作。SCA仅仅是个规范。
.png)
（1）Component
深蓝色方框（Component A和Component B）表示是Component。Component是SCA原子（最基层的组织单元），其封装了实际的业务逻辑。Component可以采用运行环境支持的任何编程技术实现。例如，Apache Tuscany项目目前支持Java、JavaScript、Ruby、Python和C++组件类型，同时为创建新的组件类型提供了扩展API。
（2）Property
Property (Component A和Component B上方的黄色方框和Composite A的黄色小方框)。Property控制Component的行为，在部署其间可以被可改变。同时Composite也可以有Property，但其Property是Component Property升级（Promote）后的Property。
（3）Service
Service是供其它Component调用时使用。在图中接口用Component方框左边的绿色箭头来表示，被称作SCA的“服务”（Service）。
（4）Reference
Component也描述了被该Component调用的其它组件的接口，在图中这样的接口用组件方框右边的粉红色箭头来表示，称为SCA的“引用”（Reference）。这些Service和Reference被连接在一起，组成一个可运行的系统。
（5）Composite
如果说Component是SCA架构中的原子，那么Composite就是SCA架构中的分子；图中的两个Component，A和B，被组装在一个更大Composite范围内，被称作Composite A。SCA的Composite描述了一个由互相连接的Component所构成的集合。正如你所看到，Composite也声明了Service和Reference，它们被暴露到Composite外部。Composite的service和Reference是Composite内部的Component的Service和Reference的升级。一个Composite内部的Component彼此连接就如同创建一个运行在同一进程中的紧耦合的应用程序。将Composite通过Service和Reference连接在一起，则形成了一个更加松耦合的系统；系统中的每一个Composite都可能运行在一个单独的进程或处理器中，在网络中通过各种的协议和传输绑定连接起来。通过这个途径SCA为独立和分布式应用提供了统一的编程模型。
（6）Wire
Wire是连接Service和Reference的连线。
（7）Promote
Promote是wire的特殊表现形式，是把Component级别Service或者Reference升级为Composite级别的连线。
（8）Domain
为了更直观地介绍domain，如下图所示：
Domain是个逻辑的概念，管理跨机器，跨进程的Composite，同时Composite也可以跨机器跨进程部署，从而可以管理分布式部署的SCA，所以Domain是个相当重要的SCA概念。其实除了Domain是管理含义外，还有外部接口界面的含义。
.png)
SOA和微服务的区别：
1、SOA喜欢重用，微服务喜欢重写
SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有复杂的依赖关系。
微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。
2、SOA喜欢水平服务，微服务喜欢垂直服务
SOA设计喜欢给服务分层(如Service Layers模式)。 我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求所有的服务都通过这个Entity服务层来获取数据。 这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。 而每个微服务通常有它自己独立的data store。 我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。
微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。 类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。 在SOA设计模式中这种情况通常会用到Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。
3、SOA喜欢自上而下，微服务喜欢自下而上
SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。 它使用Enterprise Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。 模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。SOA架构适用于TOGAF之类的架构方法论。
微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。
二、明天计划的事情：
主要学习springcloud
三、遇到的问题：
1.
解决方法：
四、收获：
1.了解SOA和SCA的概念。SOA是面向服务的编程，本质就是面向对象编程，只是一个更加宏观的概念，把面对的对象指向为面对服务，也是为了实现软件结构的高内聚，低耦合要求，强调的是每个服务模块的封闭性和整体性。SCA是实现SCA思想的一种架构模式。
返回列表
评论