SOA和微服务基本原则及对比

2017-08-20 本文已影响97人端木轩

一、面向服务设计的原则

服务可复用：不管是否存在即时复用的机会，服务均被设计为支持潜在的可复用
服务共享一个标准契约：为了与服务提供者交互，消费者需要导入服务提供者的服务契约，这个契约可以是一个IDL文件，Java接口定义，WSDL文件，甚至是接口说明文档
服务是松耦合的：服务被设计为功能相对独立，尽量不依赖其他服务的独立功能提供者
服务是底层逻辑的抽象：只有经服务契约所暴露的服务队外部世界可见，契约之外底层的实现逻辑是不可见的
服务是可组合、可编排的：多个服务可能被编排组合成一个新的服务，这允许不同逻辑抽象的自由组合，促进服务的复用
服务是自治的：逻辑由服务所控制，并位于一个清晰的边界内，服务已经在边界内被控制，不依赖其他服务
服务是无状态的：服务应当不需要管理状态信息，因此能够维持送耦合性。服务应该被尽可能设计成无状态，即便意味着要将状态管理移至他处
服务是可被自动发现的：服务发布上线后，允许被其他消费者自动发现；当服务提供者下线后，允许消费者接收服务下线通知。

SOA服务化之后，应用服务化之后给系统运维带来很大挑战：

此时，SOA服务治理是关键。SOA服务治理主要包括如下几个方面：

SOA治理最基础的方面就是监视服务的创建过程。必须对服务进行标识，描述其功能，确定其行为范围并设计其接口。创建服务时需要与使用这些服务的团队进行协调，以确保服务能够满足消费者需求，避免重复工作。

服务的生命周期通常有五个主要的阶段。

新版本的前向兼容性，灰度发布等需要按照统一的策略进行管理。

需要统一的服务注册中心支持服务的订阅发布和动态发现机制。

服务监控中心需要对服务的调用时延、成功率、吞吐率等数据进行实时采样和汇总，通过图形化报表的形式展示，以便运维人员对服务的运行质量进行实时分析和掌控。

包括服务限流、服务迁入迁出、服务升降级、服务权重调整和服务超时控制等，通过运行期的动态治理，可以在不重启服务的前提下达到快速提升服务运行质量的目标。

大规模分布式环境下海量业务/平台日志的采集、汇总和实时在线检索，支持多维度的条件检索、模糊查询，可以快速的在线查看各种系统运行日志，方便问题定位；
分布式消息跟踪，通过调用链打通业务、服务调用和异常，发现线上系统故障源；通过在线和离线调用链大数据分析，得到链路各个依赖的稳定性指标，梳理依赖链路风险表，识别系统核心功能的服务调用依赖关系，评估可能的最大风险点，针对性改进以预防风险，同时为容量规划和扩容提供数据决策依据。

服务安全访问策略有多种，例如可以通过动态生成令牌token的方式做安全访问授权，服务提供者动态生成token并告知服务注册中心，由注册中心告知是否告知消费方，这样就能在注册中心页面上做复杂的授权模型。

微服务架构（MSA）是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。

微服务架构的主要特征如下：

原子服务：“高内聚，松耦合”
高密度部署:重要的服务可以独立进程部署，非核心服务可以独立打包，合设到同一个进程中，服务被高密度部署。物理机部署，可在一台服务器上部署多个服务实例进程；如果是云端部署，则可以利用LXC实现容器级部署，以降低部署成本，提升资源利用率。
敏捷交付：真正的DevOps。
微自治：服务足够小，功能单一，可以独立打包、部署、升级、回滚和弹性伸缩，不依赖其他服务，实现局部自治。

两者的主要差异如下：

服务拆分粒度：SOA首先要解决的是异构系统应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
服务依赖：传统的SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度。
服务规模：传统SOA服务粒度比较大，多数会采用将多个服务合并打成war包的方案，因此服务实例数比较有限；微服务强调尽可能拆分，同时很多服务会独立部署，这将导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。
架构差异：微服务化之后，服务数量的激增会引起架构质量属性的变化，例如企业集成总线ESB逐渐被P2P的虚拟总线替代；为了保证高性能、低时延，需要高性能的分布式服务框架保证微服务架构的实施。
服务治理：传统基于SOA Governance的静态治理转型为服务运行态微治理、实时生效。
敏捷交付：服务由小研发团队负责微服务设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。

总结：量变引起质变，这就是微服务架构和SOA服务化架构的最大差异。