架构设计_阿里弃用dubbo后新框架_架构设计原则(6)

最后是和持久化层，包括常见的关系，半结构化和基于key-value的redis，mongoDB等，还有就是完全基于hdfs的非结构化文件存储能力。对于不同的业务场景和业务对象，往往需要底层不同的数据和存储能力进行支撑，如何形成一个完整能力的服务能力层是架构设计时候需要考虑的。

去IOE化

对于去IOE化是这两年互联网架构设计谈得最多的问题，即去掉小型机，集中存储和商用。如果简单来说下去IOE化的核心就是基于开源的类似Mysql和集群技术，通过X86服务器硬件资源来实现和原来使用IOE架构时候同样的性能和高可用性。在之前淘宝有开源的corba基于mysql来实现分布式和集群，现在有开源的MyCat来实现，核心就是提供一个DaaS服务层和封装，来实现高性能和高可用的中间件产品。

对于去IOE的热度在当前已经有所下降，这里面有两个原因一个是本身技术成熟度和CAP原则约束，一个方面的原因就是在去IOE和引入DaaS中间件后本身是增加了架构复杂度和应用开发难度。一个方面是由于DaaS层引入导入的分布式事务问题和对于跨库查询和Sql语句本身的约束增加。一个是在架构设计中就需要考虑前端业务如何进行组件化，业务对于的数据存储如何进行分区和分片，究竟如何进行水平拆分和垂直拆分。

可以讲在架构设计中的去IOE设计和前面讲到的组件化和服务化设计思路密不可分，同时在去IOE下的组件化是彻底的组件化，即组件本身对应的也是独立的，组件可以拥有完全独立的硬件资源和全生命周期管理。因此如果组件没有划分，在后期业务功能实现中就可能导致大量的跨库操作和分布式事务问题。这些都应该在架构设计阶段就思考清楚并制定清晰的架构设计约束，任何架构设计都不会有普适性的通用架构存在，架构约束定义是一个架构要发挥其高效能力的关键。

去中心化

首先来看一个最简单的场景，即客户和请求端是A，服务提供端是B，对于服务提供端已经实现为了分布式集群即(B1,B2,B3...Bn)，在这种场景下可以看到对于请求会转发不同的集群节点进行处理。但是对于这种分布式架构来看，集群是可以完全平滑弹性扩展的，但是问题关键点在于A的请求究竟应该转发到哪个B节点去处理，这里面就有一个控制层或管理节点，而对于大多数分布式应用来讲管理节点本身是很难集群化扩展的。及时当前很多分布式架构实现过程中已经实现了消息请求和数据传输的分离，但是仍然存在对于管理节点无法水平扩展的问题。

对于水平弹性扩展问题的解决，往往会引入集群技术和硬件负载均衡，但是这不是一个完全意义上的去中心化架构，当前我们说的去中心化架构都是没有统一的管理节点，完全分布式，只有在这种架构下才是完全的去中心化。要做到去中心化就涉及到几个关键点的引入，一个是请求通过sdk包在客户端的植入进行前移，即客户端发起请求的时候就已经判断清楚；其次是对于管理职责后移，即管理端后续重点是从各个集群节点准实时采集数据再进行分析。要实现第二点往往又涉及到高性能的消息中间件的引入。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26396-6.html