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

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

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

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

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

二、架构的演变过程

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

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

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

三、RPC简单介绍

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

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

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

四、分布系统的基础设施

4.一、分布式缓存

        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.二、持久化储存

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

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

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

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

五、消息系统

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

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

六、其它基础设施

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

七、系统架构演化历程

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

       数据库写入、更新的这些操做的部分数据库链接的资源竞争很激烈，致使了系统变慢。
读写分离，是把对数据库读和写的操做分开相应不一样的数据库server。

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

       Quest SharePlex就是比較牛的同步数据工具。据说比oracle自己的流复制还好。MySQL也有本身的同步数据技术。
       mysql仅仅要是经过二进制日志来复制数据。

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

oracle可以经过F5有效分配读从数据库的压力。
      解决方式：mysql有Mysql Proxy、Amoeba、Atlas；

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

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

       解决方式：Nginx，apache

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

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

       分布式数据库是系统数据库拆分的最后方法。仅仅有在单表数据规模很庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不一样的业务数据库部署在不一样的物理server上。
      解决方式：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一个基于分布式文件存储的数据库)；分布式文件系统方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs。Hadoop实现了一个分布式文件系统（Hadoop Distributed File System）

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

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

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

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

 

7.五、系统架构演化历程-业务拆分

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

描写叙述：为了应对日益复杂的业务场景。一般使用分而治之的手段将整个系统业务分红不一样的产品线。应用之间经过超连接创建关系，也可以经过消息队列进行数据分发，固然不少其它的仍是经过訪问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：
       将一个大应用拆分为多个小应用，假设新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统、 纵向拆分相对较为简单。经过梳理业务，将较少相关的业务剥离就能够。
横向拆分：
       将复用的业务拆分出来，独立部署为分布式服务，新增业务仅仅需要调用这些分布式服务、 横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
 

7.六、系统架构演化历程-分布式服务

特征：公共的应用模块被提取出来，部署在分布式server上供应用server调用。
描写叙述：随着业务越拆越小。应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统链接，终于致使数据库链接资源不足，拒绝服务。

 

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

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

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

(3) 接着，服务的调用量愈来愈大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？何时该加机器？
(4) 服务多了。沟通成本也開始上升，调某个服务失败该找谁？服务的參数都有什么约定？ 
(5) 一个服务有多个业务消费者。怎样确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比方cache写错了致使内存溢出，故障不可避免。每次核心服务一挂，影响一大片。人心慌慌。怎样控制故障的影响面？服务可否够功能降级？或者资源劣化？ 

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

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

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

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

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

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

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