面向服务的体系架构（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使得开发包括网络分布式多程序在内的应用程序更加容易。

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

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

6、其他基础设施

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

7、系统架构演化历程

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

       数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢。
读写分离，是把对数据库读和写的操作分开对应不同的数据库服务器。主数据库提供写操作，从数据库提供读操作。当主数据库进行写操作时，数据要同步到从的数据库，有效保证数据库完整性。
       Quest SharePlex就是比较牛的同步数据工具，听说比oracle本身的流复制还好，MySQL也有自己的同步数据技术。
       mysql只要是通过二进制日志来复制数据。通过日志在从数据库重复主数据库的操作达到复制数据目的。这个复制比较好的就是通过异步方法，把数据同步到从数据库，读的操作怎么样分配到从数据库上？应该根据服务器的压力把读的操作分配到服务器，而不是简单的随机分配。mysql提供了MySQL-Proxy实现读写分离操作。不过MySQL-Proxy好像很久不更新了。oracle可以通过F5有效分配读从数据库的压力。
      解决方案：mysql有Mysql Proxy、Amoeba、Atlas；

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

        为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
       解决方案： Nginx，apache

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

       发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作数据库采用分布式数据库（所有节点的数据加起来才算是整体数据），文件系统采用分布式文件系统任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
       分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
      解决方案：mysql有mysql cluster 和 Mysql Proxy;mongodb(是一个基于分布式文件存储的数据库)；分布式文件系统方案：CEPH、glusterfs、fastDFS、mogilefs 、moosefs，Hadoop实现了一个分布式文件系统（Hadoop Distributed File System）

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

特征：系统引入NoSQL数据库及搜索引擎。
描述：随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

 

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

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

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

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

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

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

 

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

(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？ 
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？ 

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

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

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

callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。

Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的.get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。

Oneway模式：客户端调用完继续执行，不管接收端是否成功。

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