[新人报到] 设计构架

淘宝开放平台（TaoBao Open Platform，简称TOP）的整个架构体系是组件化体系架构，可以是很少的几个基础组件构成的Skeleton，也可以是融入了商业想象的Amazing Architecture。这里就通过对于这些组件的罗列，描述出在TOP这个大体系中，各个组件所处的地位及作用。TOP的“兵器谱”是在现阶段商业需求及平台非业务性需求指导下形成的，未来TOP将继续发展，“兵器谱”也会不断演进。
    下图是整个TOP当前的一个组件结构图：
    图中，红色虚线就是TOP的Skeleton。TOP当前从业务模块功能角度来划分，可以分成三个层次：基础平台组件层，基础业务组件层，普通业务组件层。基础平台组件层，倾向于平台级别功能满足及对平台稳定性，可用性的支持。基础业务组件层，是介于平台服务于普通业务服务之间的组件，部分利用了平台基础组件层的组件，来抽象出一层公用业务服务组件，为业务组件提供通用的基础支持。
    安全组件
    安全组件主要从四个角色去考虑整体的安全策略及具体的实施方案，这四个角色是：用户，应用，平台，服务。
    平台本身的安全主要是基于在大并发和大流量的情况下，保证平台自身稳定性和可用性，同时也要兼顾在平台开放的服务不相互干扰和影响。因此采取服务分流隔离机制，通过虚拟配置及软负载方式将服务请求动态分流和隔离，保证了服务之间相互的独立性，同时也充分利用TOP的能力。频率控制及流量控制除了保护TOP自身不受到攻击，也为后端服务提供者作了天然的一个保护屏障，保证服务请求压力可以在TOP上可控，防止流量直接压倒服务提供者。用户隐私安全在淘宝尤为重要，用户信息的安全性也在淘宝开放的过程中被放到了首位。在开放平台设计中，除了采用普通开放平台的认证模式以外（OAuth类似流程），还在服务调用过程中通过区分应用角色来限制对于用户信息的获取和使用。同时针对不同的应用类型（插件，Web应用，客户端应用，手机应用）都有各自不同的用户授权方式，保证用户的知情权。App的安全其实也是为了保证对服务的请求及对用户信息的获取不被不法的应用信息盗取者所利用，根据应用角色及自己对于安全的需求，采取多种方式或者组合的方式来实现App信息的保密性，保护App自身安全，也保证了平台服务的数据安全。服务安全指的是对于服务来说分成了几个层级，不同层级的服务对于安全级别的要求不同（不需要交验应用身份，需要交验应用身份，需要用户授权，用户可选择授权等），在应用访问服务的时候，就会需要根据服务级别的不同采用不同的访问控制流程。根据上述的四个角色对于安全的考虑，通过应用角色的定义，服务虚拟组的编排，黑名单（频率控制及流量控制），多模式用户令牌等手段，形成了多种模式的安全控制流程。
    服务路由组件
    服务路由是开放平台最基本的功能，如果排除商业因素，那么对于TOP最基本上来看可以看作一个服务路由器，服务路由主要的功能如下图展示：
    服务路由组件需要支持多服务类型的服务接入，不同服务类型主要表现在两个维度：1.服务对外的展现方式（REST OR RPC），这两种形态的服务没有任何好坏之分，只是根据各自的系统形态来选择采用哪一种模式来对外暴露，RPC比较符合过去应用开放的风格，REST比较适合面向资源的架构。同时对于同步，异步，通知，大数据量的服务，都会有不同的接入方式和调用方式支持，满足各种业务场景的需求。多通信协议支持，表示服务请求到了TOP以后，TOP负责将请求继续发送给服务提供者，不论服务提供者采用什么方式和TOP交互，最终将得到的结果返回给客户，服务调用者将会对后端的服务请求过程透明，同时可以使TOP很容易接入一些传统遗留系统的服务，或者是对通信有特殊需求的服务。特性支持主要是会有对内容的一些特殊处理，例如压缩，在CS或者手机应用交互过程中，就会需要对数据量有所压缩，满足业务需求。
    监控告警组件
    下图是监控告警组件的基本功能图
    监控和告警模块在TOP中起到越来越重要的作用，访问量逐日膨胀，运行期TOP是一个黑盒，无法知晓当前系统实际的健康状况，当出现问题以后比较难以定位。服务监控主要是服务质量（响应时间），短时间段内的服务请求峰值，和阶段性的趋势。系统和平台主要是对底层基础组件的监控，同时及时地通知TOP负责人处理线上即将要发生的事情。对于应用的监控通常就是从客户端和服务端两面对于应用当前的情况作汇总分析。当监控发现异常以后，就交由告警部分按照一定的发送策略给相关的负责人，在第一时间将问题解决。
    日志组件
    日志组件和其他系统的日志组件基本没有太大的区别，只是在对于海量数据写出和获取的方法做了优化（例如异步分页批量输出等）。日志组件主要负责，打点，收集，分析，数据库记录，归档。