soa服务划分实例

 

传统的IT系统在向互联网化方向转型时，通常需要面对以下几个技术挑战。

 

     ■ 性能。用户体验是影响转化率的重要因素，据统计如果4秒钟打不开网站，将有60%的顾客会流失，糟糕体验将导致大量的客户选择放弃或从竞争对手处购买服务。如何在高并发访问的情况下保证系统的低延迟响应，以提升用户体验。

 

     ■ 伸缩性。互联网/移动互联网用户的访问行为是动态的，在一些特殊的热点引爆后，流量能够通常达到平时的10倍甚至几十倍以上。如何快速响应业务爆发时的资源开销需求，提供无差别的用户体验。

 

     ■ 容错与最大可用性。互联网应用系统基于分布式计算架构部署，基于大量的x86服务器和通用网络设备。而机器一定会坏，当机器数量到一定规模时，小概率事件就成为常态，当硬件出现故障时应该如何自动化处理，人一定会在开发中写出Bug，怎么进行系统的损害控制。如何基于单机QPS和并发数对服务端和客户端进行限流，实现动态流量分配，识别服务之间的依赖链路风险和系统重要功能点依赖，评估最大可能的风险点，分布式系统最大可用性故障检测，对故障模块进行隔离，对未完成事物进行Rollback，通过牺牲非关键功能通过优雅降级保证核心功能可用。

 

     ■ 容量管理。系统性能一定会到达瓶颈，如何进行更科学的容量评估和扩容，自动计算前端请求与后端机器数量的对应关系，对软硬件容量需求进行预测。

 

     ■ 服务化。如何将业务逻辑功能抽象成一个个原子服务，对服务进行封装和组合，并基于分布式系统环境部署，以实现更灵活的业务逻辑和流程。如何从业务视角厘清这些服务的关系，对大规模分布式系统中的单条服务调用链进行跟踪与展现，并能够及时发现服务调用异常。

 

     ■ 低成本。随着系统的演进性能指标不断发生变化，如何保证以最低成本满足特定访问量的要求。

 

     ■ 自动化运维管理。不断发展的大规模系统需要不断维护、快速迭代和优化。如何应对从一台到上千台甚至上万台服务器的运维量变，通过自动化工具和流程管理大规模软硬件集群，对系统进行快速部署、升级、扩容和维护。

 

     随着业务的快速发展，淘宝技术架构经历从最初的LAMP架构，到IOE架构，再到分布式架构，最后到现在的云计算平台架构这一变化过程在不断解决上面的技术问题。

 

 

  淘宝技术架构变迁

 

     自2003年创立以来的，淘宝业务发展非常迅速，几乎是每年以100%的速度在成长。创立之初，为了快速上线，抢占市场，选择了当时流行的LAMP架构，用PHP作为网站开发语言， Linux作为操作系统，Apache作为Web服务器，MySQL为数据库，用了三个月不到的时间淘宝就上线了。当时整个网站应用服务器大概10台左右，MySQL数据库采用了读写分离、一主两备的部署方式。

 

     2004年在淘宝业务发展的推动下，我们参考电信运营商、银行等的一些企业解决方案，将LAMP架构改造为Oracle+IBM小型机的数据库架构和EMC存储方式（图2）。虽然方案成本昂贵，但性能非常好。同时，随着网站流量的增加，系统显得有些不堪重负。当时最担心的问题是网站流量如果持续增加，交易量持续增加，网站的系统架构怎么设计？如何选择数据库？如何选择缓存？如何构建业务系统？……后来参考eBay的互联网设计架构，设计了一个Java的技术方案，并使用了非常多的Java开源产品。例如，选择当时比较流行的JBoss，作为应用服务器；选择一个开源的IOC容器Spring，来管理业务类；封装了一个数据库访问工具IBatis，作为数据库和Java类的Object-Reletionship映射工具。另外，对于商品搜索功能，采用自己开发的ISearch搜索引擎来取代在Oracle数据库中进行搜索，降低数据库服务器的压力。做法比较简单，每天晚上全量将Oracle小型机的数据dump出来，Build成ISearch的索引，当时商品量也不大，一台普通配置的服务器，基本上可以将所有的索引都放进去，没做切分，直接做了一个对等集群。

做了一个对等集群。

 

 从2006年开始，淘宝为了改善用户体验，开始建立自己的CDN站点，由于淘宝的主要流量来源于各种商品图片、商品描述等静态数据，自建CDN可以使这些资源离用户更近，提升用户访问速度，改善用户浏览网站的体验。

 

     2007年，淘宝全年的交易额超过400亿元，平均近1亿多一天，每天有100多万笔交易被创建。当时面对的几个主要问题是：一些系统的流量非常大，如商品详情等，如果直接访问数据库，会导致数据库压力非常大；如用户信息，访问一个页面，都需要查询买家信息、卖家信息、显示出买家的信用、卖家的服务星级等。此时，淘宝采用分布式缓存TDBM（Tair的前身）将这些热点静态数据缓存在内存中，提高访问性能。另外，将自己研发的分布式文件系统TFS部署在多台x86服务器上，取代商业的NAS存储设备来存储淘宝的各种文件信息，如商品图片、商品描述信息、交易快照信息，来达到降低成本和提高整体系统的容量和性能的目的，同时可以实现更灵活的扩展性。第一期上线大概200台TFS服务器。另外，将ISearch搜索引擎改为分布式架构，支持水平扩展，部署了48个节点。图3展示了这一架构思路。

 

 

此时引入缓存、分布式存储和分布式搜索引擎都是为了解决oracle的数据库瓶颈，此时还没有达到“去IOE”。

去IOE是阿里在2008年才提出来的，为了彻底解决Oracle数据库集中式架构的瓶颈问题。

2008年初，为了解决Oracle数据库集中式架构的瓶颈问题（连接数限制、I/O性能），将系统进行了拆分，按照用户域、商品域、交易域、店铺域等业务领域进行拆分，建立了20多个业务中心，如商品中心、用户中心、交易中心等。所有有用户访问需求的系统，必须使用业务中心提供的远程接口来访问，不能够直接访问底层的MySQL数据库，通过HSF这种远程通信方式来调用业务中心的服务接口，业务系统之间则通过Notify消息中间件异步方式完成调用。图4是淘宝的分布式架构图。

（是的，阿里在2008年就已经开始使用分布式服务框架hsf，俗称“好舒服”，区别tfs，tfs是阿里的分布式文件系统。

在2010年的csdn博客 淘宝(taobao)HSF框架就介绍了这个框架：

  随着网站访问量增加，仅仅靠增加机器已不能满足系统的要求，于是需要对应用系统进行垂直拆分和水平拆分。在拆分之后，各个被拆分的模块如何通信？如何保证性能？如何保证各个应用都以同样的方式交互？这就需要一种负责各个拆分的模块间通信的高性能服务框架(HSF)。。。

）

 

 

     从2010年开始，淘宝网重点着眼于统一架构体系，从整体系统层面考虑开发效率、运维标准化、高性能、高可扩展性、高可用、低成本方面的要求，底层的基础架构统一采用了阿里云计算平台（图5），使用了SLB、ECS、RDS、OSS、ONS、CDN等阿里云计算服务，并通过阿里云服务提供的高可用特性，实现双机房容灾和异地机房单元化部署，为淘宝业务提供稳定、高效和易于维护的基础架构支撑。

 

     在从IOE架构最终向云计算平台技术架构转移的过程中，主要面临以下几个技术挑战。

 

     ■ 可用性：脱离小型机和高端存储的高冗余机制，采用基于PC服务器的分布式架构的云计算平台能否做到高可用。

 

     ■ 一致性：Oracle基于RAC和共享存储实现的物理级别一致性，基于RDS for MySQL能否达到同样的效果。

 

     ■ 高性能：高端存储的I/O能力很强，基于PC服务器的RDS能否提供同样甚至更高的I/O处理能力，MySQL和Oracle对SQL的处理性能是否相同。

 

     ■ 扩展性：业务逻辑如何拆分，如何服务化，数据分多少库分多少表，什么维度分，后期二次拆分如何更方便等。

 

     基于阿里云计算平台，通过采用合适的技术策略和最佳实践，包括：应用无状态，有效使用缓存（浏览器缓存、反向代理缓存、页面缓存、局部页面缓存、对象缓存和读写分离），服务原子化，数据库分割，异步解决性能问题，最小化事物单元，适当放弃一致性。以及自动化监控/运维手段包括监控预警、配置统一管理，基础服务器监控，URL监控，网络监控，模块间调用监控，智能分析监控，综合故障管理平台，容量管理。可以很好地解决以上问题，从而达到整体系统的高可扩展性、更低的成本、更高的性能和可用性的实现效果。

 

注（原创）：

在笔者所在的互联网税务公司中，将服务划分为纳税人域、申报缴税域、发票管理域，

对应nsr（nsr-hxfw-java等）、sbzs(sbzs-hxfw-java等)、sxsq(sxsq-hxfw-java等)

 

 

淘宝(taobao)架构发展历程

一、淘宝系统架构    

     2008年，淘宝每天增加800G的数据，高峰期超过30G/s，处理超过1000G的日志，处理40亿次用户请求信息。淘宝架构发展经历了三个阶段。

     第一阶段（V1.0）

     采用经典的LAMP结构，mySQL采用M-S模式，实现了读写分离。后期采用了SQLrelay中间件技术。

     第二阶段（V2.0）：

     这一阶段，用java替换了php，引入了MVC框架，使用Antx管理项目，使用了搜索引擎ISearch。在后期，逐渐引入了SPring框架，抛弃了EJB；对数据库实现分库存储；使用了分布式存储和分布式缓存，对搜索引擎升级。

     第三阶段（V3.0）：

     在现有框架下增加了应用透明性和数据透明伸缩性的尝试。在应用透明性方面，有了session框架，高性能服务框架HSF，消息系统Notify，建立了业务中心；在数据库透明伸缩性方面，引入分布式数据层TDDL。

 

二、WEB架构设计

    WEB应用一般采用分层结构，服务器端主要包括展现层、业务逻辑层和持久层。

    1.展现层要实现可扩展，关键是session的处理。

    2.业务逻辑层要实现透明可扩展

•  建立领域模型
•  统一、隔离
•  无状态业务层
•  负载均衡

    3.持久层透明可扩展

•   数据库按功能垂直分割，按规则水平分割
•   时间换空间或空间换时间
•   牺牲一定的一致性
•   二八原则

 

三、关键技术

    1.session处理方式

• 粘性session
• session复制
• 集中式session
• 不是有session

    2.分布式存储

      分布式存储是相对于集中式存储的一种处理方式，把数据存在在不同的节点上，通过查询位置服务器找到数据所在的节点。提高数据存储的可扩展性和查询效率。

    3.分布式缓存

    见http://rdc.taobao.com/blog/qa/?p=5299，关于Tail的介绍