面向服务的体系架构（SOA）

面向服务的体系架构（SOA）

1、面向服务的体系架构（SOA）

面向服务的架构（service-oriented architecture）是Gartner于2O世纪9O年代中期提出的面向服务架构的概念。2002年的l2月。Gartner提出“面向服务的架构(SOA)”是“现代应用开发领域最重要的课题”之后。国内外计算机专家、学者掀起了对SOA的积极研究与探索。

在分布式的环境中。将各种功能都以服务的形式提供给终于用户或者其它服务。现在，企业级应用的开发都採用面向服务的体系架构来满足灵活多变。可重用性高的需求。

2、架构的演变过程

随着互联网技术迅速发展和演变。不断改变的商业化应用系统越来越复杂，由单一的应用架构到垂直的应用架构。但还是面临的扩容的问题。流量分散在各个系统中，尽管体积可控。但对开发者和维护人员带来极麻烦。此时，将核心的业务单独提炼出来作为单独的系统对外提供服务。

达成业务之间复用。系统也将演变成分布式系统架构。

分布式架构是各组件分布在网络计算机上、组件之间只通过消息传递来通信并协调行动。

3、RPC简单介绍

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不须要了解底层网络技术的协议。RPC协议假定某些传输协议的存在。如TCP或UDP，为通信程序之间携带信息数据。

在OSI网络通信模型中。RPC跨越了传输层和应用层。

RPC使得开发包含网络分布式多程序在内的应用程序更加easy。

4、分布系统的基础设施

4.1、分布式缓存

Memcache 高性能对象缓存系统。在内存中维护一个巨大的基于key-value的hashtable。能够用来缓存不论什么数据。(对象通过序列化后。转换成二进制缓存)当空间不够用的时候採用LRU算法淘汰数据。网络连接处理採用libevent,高效低耗。memcache採用的是基于tcp连接的memcache协议，协议能够承载文本行和结构化数据，文本行主要用来传输指令。结构化数据主要用来数据传输。

        第二种做法是讲session缓存在一个集群上面。比如memcache集群。

这样系统的吞吐量高，并且有利于对session的刷新(session都是有有效期的。须要定期刷新)，可是缺点也显而易见： 一旦cache集群重新启动。所有内存里面的session将所有丢失。

Redis是一个高性能的key-value数据库，也可以做缓存。redis丰富的数据结构，其hash，list，set以及丰富的数据结构和超高的性能以及简单的协议，让Redis可以非常好的作为数据库的上游缓存层。可是我们会比較操心Redis的单点问题，单点Redis容量大小总受限于内存。在业务对性能要求比較高的情况下，理想情况下我们希望全部的数据都能在内存里面，不要打到数据库上。所以非常自然的就会寻求其它方案。
比方。SSD将内存换成了磁盘，以换取更大的容量。

4.2、持久化储存

Hbase、MySQL、Redis传统的IOE方案： IBM小型机Oracle数据库 EMC持久储存成本非常高。传统的数据库提供完整地acid功能。而且提供丰富的内连接外连接关联查询等功能。可是，对于高并发应用来说，有的时候会牺牲关联查询事务数据一致性（降级为终于一致性）。

Hbase有更好地伸缩能力。更适合海量数据储存。

并发写入十分出色，可以支持多regionserver同一时候写入。可是其本身对于查询的支持力度有限，比方group by order by join等。

Redis是一个key-value类型的数据库，可以支持更高的并发量，并且支持的数据类型也比其它的key-value数据库的数据类型多。

5、消息系统

JMS即Java消息服务（JavaMessage
Service）应用程序接口。是一个Java平台中关于面向消息中间件（MOM）的API。用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与详细平台无关的API，绝大多数MOM提供商都对JMS提供支持。

比方开源的ActiveMQ 是Apache出品。最流行的。能力强劲的开源消息总线。

6、其它基础设施

在分布式系统应用中，上面说的系统外。还有搜索引擎系统、文件系统、日志系统、数据仓库等等。

7、系统架构演化历程

7.1、系统架构演化历程-数据库读写分离

数据库写入、更新的这些操作的部分数据库连接的资源竞争很激烈，导致了系统变慢。

读写分离，是把对数据库读和写的操作分开相应不同的数据库server。

主数据库提供写操作。从数据库提供读操作。当主数据库进行写操作时，数据要同步到从的数据库。有效保证数据库完整性。

Quest SharePlex就是比較牛的同步数据工具。听说比oracle本身的流复制还好。MySQL也有自己的同步数据技术。

       mysql仅仅要是通过二进制日志来复制数据。

通过日志在从数据库反复主数据库的操作达到复制数据目的。这个复制比較好的就是通过异步方法。把数据同步到从数据库。读的操作怎么样分配到从数据库上？应该依据server的压力把读的操作分配到server，而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。只是MySQL-Proxy好像非常久不更新了。

oracle能够通过F5有效分配读从数据库的压力。

      解决方式：mysql有Mysql Proxy、Amoeba、Atlas；

7.2、系统架构演化历程-反向代理和CDN加速

为了应付复杂的网络环境和不同地区用户的訪问。通过CDN和反向代理加快用户訪问的速度，同一时候减轻后端server的负载压力。CDN与反向代理的基本原理都是缓存。

       解决方式：Nginx，apache

7.3、系统架构演化历程-分布式文件系统和分布式数据库

发现分库后查询仍然会有些慢，于是依照分库的思想開始做分表的工作数据库採用分布式数据库（全部节点的数据加起来才算是总体数据），文件系统採用分布式文件系统不论什么强大的单一server都满足不了大型系统持续增长的业务需求。数据库读写分离随着业务的发展终于也将无法满足需求，须要使用分布式数据库及分布式文件系统来支撑。

分布式数据库是系统数据库拆分的最后方法。仅仅有在单表数据规模很庞大的时候才使用，更经常使用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理server上。

      解决方式：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一个基于分布式文件存储的数据库)；分布式文件系统方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs。Hadoop实现了一个分布式文件系统（Hadoop
Distributed File System）

7.4、系统架构演化历程-使用NoSQL和搜索引擎

特征：系统引入NoSQL数据库及搜索引擎。

描写叙述：随着业务越来越复杂。对数据存储和检索的需求也越来越复杂，系统须要採用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。

应用server通过统一数据訪问模块訪问各种数据，减轻应用程序管理诸多数据源的麻烦。

7.5、系统架构演化历程-业务拆分

特征：系统上依照业务进行拆分改造，应用server依照业务区分进行分别部署。

描写叙述：为了应对日益复杂的业务场景。通常使用分而治之的手段将整个系统业务分成不同的产品线。应用之间通过超链接建立关系，也能够通过消息队列进行数据分发，当然很多其它的还是通过訪问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：

       将一个大应用拆分为多个小应用，假设新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统、纵向拆分相对较为简单。通过梳理业务，将较少相关的业务剥离就可以。

横向拆分：

       将复用的业务拆分出来，独立部署为分布式服务，新增业务仅仅须要调用这些分布式服务、横向拆分须要识别可复用的业务，设计服务接口，规范服务依赖关系。

7.6、系统架构演化历程-分布式服务

特征：公共的应用模块被提取出来，部署在分布式server上供应用server调用。

描写叙述：随着业务越拆越小。应用系统总体复杂程度呈指数级上升，因为全部应用要和全部数据库系统连接，终于导致数据库连接资源不足，拒绝服务。

8、分布式服务应用会面临哪些问题?

(1) 当服务越来越多时，服务URL配置管理变得很困难，F5硬件负载均衡器的单点压力也越来越大。

(2) 当进一步发展。服务间依赖关系变得错踪复杂。甚至分不清哪个应用要在哪个应用之前启动。架构师都不能完整的描写叙述应用的架构关系。

(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务须要多少机器支撑？什么时候该加机器？

(4) 服务多了。沟通成本也開始上升，调某个服务失败该找谁？服务的參数都有什么约定？ 

(5) 一个服务有多个业务消费者。怎样确保服务质量？

(6) 随着服务的不停升级，总有些意想不到的事发生，比方cache写错了导致内存溢出，故障不可避免。每次核心服务一挂，影响一大片。人心慌慌。怎样控制故障的影响面？服务能否够功能降级？或者资源劣化？

9、分布式架构下系统间交互的5种通信模式

request/response模式（同步模式）：client发起请求一直堵塞到服务端返回请求为止。

Callback（异步模式）：client发送一个RPC请求给server。服务端处理后再发送一个消息给消息发送端提供的

callback端点。此类情况很合适下面场景：A组件发送RPC请求给B，B处理完毕后，须要通知A组件做兴许处理。

Future模式：client发送完请求后，继续做自己的事情，返回一个包括消息结果的Future对象。client须要使用返回结果时，使用Future对象的.get(),假设此时没有结果返回的话，会一直堵塞到有结果返回为止。

Oneway模式：client调用完继续运行。无论接收端是否成功。

Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达。请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。