典型系统架构设计讨论.doc

实用标准文案 精彩文档 岑文初：模块化来降低耦合性时如何把握模块划分的粒度？如何权衡复用性与粒度过细导致依赖复杂的矛盾？ 杨海朝：耦合性是影响软件系统复杂程度和设计质量的重要因素，模块化设计的目标是建立模块间耦合度尽可能松散的系统，通过尽量使用数据耦合，少用控制耦合，限制公共耦合的范围和一定要避免使用内容耦合来降低接口的复杂性。 在系统架构中模块化设计对于降低耦合性有非常重要的作用，相关的功能合在一起，不相关的功能分离开来。 模块划分的粒度决定着最终划分结果的合理性和有效性。模块划分的粒度越细，越易于定义和开发，但随着模块数的增加，模块之间的接口也随之增加，使得各个模块在组装成系统消耗的时间增加，同时加大了整个系统测试的复杂度。模块划分的粒度越粗，越有利于整个系统的组装，整个系统的测试复杂度也降低，但整个系统的灵活性下降，难以满足用户对系统的多样性需求。 模块划分的粒度是一个不太容易把握的问题，不同的产品和项目有不同的划分粒度方法。模块化的粒度需要根据模块的三大特征（相对独立性、互换性、通用性）来把握。每个模块的聚合度越高，耦合性就越低，反之亦然。在做模块划分时，应使模块之间尽可能独立，块内联系尽可能大，块间联系尽可能小，功能模块逐层分解和细化，直至形成若干容易编写的模块。同时还需要结合模块的功能、模块的规模、模块的出入口等诸多因素综合考虑。模块划分的粒度越小，通用范围广，可在较多应用进行复用，但其较小的粒度组装过程烦琐，会导致复用效率降低。反之，模块划分的粒度越大，组装的步骤越少，可复用效率越高，但其复用范围受到限制。 岑文初：如何处理高并发系统中缓存失效的场景？ 杨海朝：从硬件到操作系统，从系统软件到应用软件，我们随处都可以看到缓存的身影。缓存在Web2.0网站中发挥着越来越重要的作用，特别是大流量的高并发系统。缓存在带来性能提升和支持高并发的同时，也带来另一个问题，如果缓存宕机导致所有的缓存失效，所有的流量都压到后端的服务上，例如数据库层。这时，后端服务因为压力过大无法提供服务或快速响应，缓存因为等待后端请求的响应而“热”不起来，最终导致“雪崩”问题。在高并发系统中，解决缓存失效有以下三个思路。 使用Consistent Hashing算法。把数据缓存分片，减少缓存宕机对服务的影响范围。Consistent Hashing能最大限度地抑制Hash键的重新分布，同时要取得比较好的负载均衡的效果，需要在服务器数量比较少时，增加虚拟节点来保证服务器能均匀地分布在圆环上，最大限度地减小服务器增减节点时产生的缓存重新分布问题。 缓存多份。通过应用写多份缓存，或应用写一份缓存由中间件把此份缓存复制多份，在缓存宕机时能切换到另一份缓存上，减少缓存宕机对后端数据存储的影响。这种方式最好采用缓存之间的复制，减少应用开发的复杂度。 解决高并发系统中的缓存失效问题，需要结合业务逻辑进行综合考虑。 实现缓存持久化或半持久化。所谓的持久化就是定期把缓存里面的数据刷到磁盘，保存起来，在缓存失效时能保证大部分数据仍然有效，例如使用Redis或MemcacheDB把一些数据存到磁盘。可能有人会说：“是否在刷磁盘那一刻会影响缓存的高效性？”这可以考虑通过高端硬件（例如Fushion IO或SSD作为存储设备），来减少刷Cache过程中减少对服务的影响。 这些仅仅是实现的三个思路，各有利弊。解决高并发系统中的缓存失效问题，需要结合业务逻辑进行综合考虑。 岑文初：目前是如何做好应用的依赖监控的？例如依赖缓存，是否知道缓存的命中率情况、使用率等；依赖外部服务，是否知道外部服务的消耗时间、成功失败情况等。 杨海朝：应用监控日益成为保障系统安全运行不可或缺的工具，在提高系统可用率和故障的预警能力、最大限度地缩短故障修复时间方面，日益显示出其重要程度。 此外，对应用依赖的服务的监控也非常重要，目前可以建立一整套监控体系，这套监控体系不仅监控应用自身，同时也对外部服务进行监控。应用在调用依赖服务时，打印应用调用的详细日志，记录调用的返回时间，以及成功与否，同时要求外部或依赖服务提供一个统一的接口，用来返回每次调用消耗的时间以及失败率。通过对这些日志的实时分析来发送邮件和短信报警。 岑文初：系统是否有对内或者对外提供服务，如何管理服务的使用权限，如何做服务升级？ 杨海朝：在系统中服务的使用权限至关重要，特别是既提供对内服务又提供对外服务的系统。 目前管理服务的使用权限，设置白名单是最简单的方式。通过设置白名单，只有在白名单里面的用户和来源IP才能访问服务，其他的都无权访问。外部调用服务也通过使用appkey的方式，简单地说是API接口的钥匙，只有通过这个钥匙才能打开API的大门，从而获取数据，同时对appkey的申请设置一系列流程来保证其安全性。根据这些appkey来