分布式系统架构实践.docx

分布式系统架构实践

五彩石项目并没有以淘宝网或者淘宝商城的架构为基础进行演化式的改进，而是进行了比较彻底的重构，是一次全新的架构升级，是分布式技术跨时代之进步。 在做系统整合之前，整个架构和非互联网的软件厂商架构是一样的，基础架构基于商业数据库、小型机、高端存储设备，业务系统架构是端到端的烟囱式架构。 简单来说，每个业务版块都是一个独立系统，公共的数据都是访问数据库的，没有形成公共的服务层。端到端的架构优势是小规模团队作战，速度会很快，各种复杂的需要一般都只需在一个系统即可完成，而且研发同学对整个系统都很熟悉，系统运维都比较简单，同时系统的稳定性也比较高。 随着业务复杂度的提升，系统规模的不断扩展，这种架构也开始出现问题。包括如下挑战： 业务研发效率比较低 业务研发效率也导致了业务的扩展性受限，做一个新的市场也必须重新开始建设，而不能重用一些业务模块。 系统扩展性较弱 因为数据库连接的关系。应用服务器的扩展规模受限制，别外数据库本身的容量也会因为小型机的计算能力而受限。 技术升级受限 比如要对数据库进行扩展或者修改，需要修改多个系统，然后再对多个系统进行回归测试，同样对热点数据增加缓存，也需要对多个系统进行修改。 通过抽象和梳理，本质上我们需要解决的第一个问题，就是业务的扩展性问题，然后需要解决因为这个问题带来的技术扩展性问题。 1、业务扩展性问题之解决 为了解决业务扩展性问题，首先需要建立共享服务层。把公共的业务元素抽离出来形成共享的服务。 比如taobao.com、tmall.com、ju.taobao.com等应用，这些都需要用到会员服务，那么就把会员服务作为共享服务抽取出来，任何系统需要获取会员信息时只需通过调用会员服务的API就可以，而不需要每个业务方自己再开发一套会员系统。 同样思路，把电商业务公共的服务，如商品服务、交易服务、营销服务、店铺服务、推荐服务、库存、物流等从各个业务抽离出来建设成共享服务，后续新建的业务市场均基于这些公共的电商元素来构建。 共享服务层的建立很好地对横向业务提供了统一的数据和服务收口，例如手机淘宝、安全、商家服务这三个横向的业务就非常依赖共享服务。 如下列表： 手机淘宝通过共享服务得到了业务输出的一致性和统一性 安全上，比如对商品数据做统一治理 商家服务则使用了共享服务开发TOP平台，来对接外部商家的工具包 各个共享服务之间形成了比较的隔离，保障各个共享服务独立的发展空间，每个共享服务之间有互相关联，又互相独立。 在系统建设上，把交易和商品两个服务中心完全独立的团队和独立的系统去建设。 商品服务中心和交易服务中心是完全独立的两套共享服务，所以在业务发展层面比较独立，系统间又不互相影响。 这使得商品相关的业务全部封闭在商品服务中心里，交易相关的业务全部封闭在交易服务中心里，架构的域之间形成低耦合、高内聚。由于隔离做得比较好，没有业务之间的复杂交错，所以各个业务领域发展创新不受限制。 值得一提的案例就是早期支付业务慢慢成为支付宝，物流业务发展为菜鸟物流，而TOP从给商家提供API演化为服务商家的聚石塔。 2、技术扩展性问题的解决 第二个问题就提技术扩展性。『房子千奇百怪，但是砖头都是一样的』。 利用共享服务解决了业务扩展性的问题，它的好处是新构建一个业务市场变得非常容易和快捷，同时任何数据结构的变化只需在一个地方改变。 带来的挑战是系统分布式后对于研发来说，要关注分布式本身。这是我们不希望的，我们希望开发人员仍然像之前开发单机版的软件一样开发软件，把分布式的控制在一些通用的组件里面。 这就需要引入解决分布式问题的中间件技术。 当时并没有商业软件可以使用，也没有合适的开源产品可以选。五彩石项目第一次大规模使用了中间件。系统分布式后，需要有一套统一的组件来解决分布式引发的共性技术问题。比如提供服务的发现机制、提供服务的分组路由机制、同机房优先机制等。我们将其沉淀在一个框架里，这个框架被称为HSF。 为了解决单库性能瓶颈问题，使用分库分表的技术，这个技术被沉淀在TDDL框架上面。 为了解决分布式事务的性能问题，把原本一个事务的工作拆成了异步执行，同时必须要保证最终数据的一致性，我们采用了消息发布订阅的方式来解决，这个消息框架就是Notify。 有了HSF、TDDL、Notify这『三大件』，有效地解决了应用分布式后引发的技术扩展性问题，同时让整个系统的技术架构变得依旧如当初一样的简。 如果系统计算能力不够，基本上能做到只需要增加服务器即可。共享服务层和分布式中间件使频繁的业务变化封闭在了一个适合的系统层，同时技术的变化也隔离在了一个合适的范围。如下图所示： 小结 为了解决业务扩展性问题，通过抽取共享服务层，在非常低的试错成本下涌现出来大量新的业务市场，推动了阿里电商业务的快速发展，同时共享服务