架构师手记15个性化标签系统的需求分析

1、第第 页共8页得业务用户基本上不愿意用本系统，一些原本可以让他们自助的工作，比如目标用户群的下载或导入，都需要IT人员来执行。对策：把标签的定义（业务人员能看懂的）和标签的IT配置信息（用于计算）分离。从设计上区分业务人员的界面和IT配置人员的界面，并用权限控制不同角色能访问的界面。2.8.目标用户群的计算速度较慢，另外，目标用户群数据较大，无法实时查询讨论：由于标签计算涉及的数据量大，算法可能很复杂，导致计算过程较长，也无法满足目标用户群实时查询的需求。对策：本系统的定位就是以批处理的方式负责生成目标用户群数据，并不提供实时查询的功能。实时查询的需求由其它系统提供。这实际上是个性化标签系统的

2、定位问题。2.9.与其它系统的交互难点：有很多其它系统都需要以不同的方式来获取目标用户群的数据，如何最小化未来不断变更的集成接口开发工作？对策：本系统只提供唯一并且统一的文件交互接口，对于其他系统而言，需要把请求参数按规定格式写成文件，上传到指定FTP服务器指定目录下，本系统收到请求后，会在标签计算完成后，把目标用户群数据按规定格式，上传到指定FTP服务器指定目录下。在这个虚构的场景中，我们完全有权力说，我们只提供一种而且就这一种接口。2.10.用户行为数据抽取的问题这个难点只适应部分公司。难点：某些公司的系统是由很多松耦合的服务组合的。服务相互之间并不清楚对方的实现细节。每个服务都自己写日志

3、。每个服务的日志都是单独的数据存储，而且日志格式不同。这就造成了一个潜在的问题，一个单一的用户请求，会请求多个服务，造成多个服务记日志。所以需要聚合多个服务的日志，才能组成一个完整的用户日志。所以需要有人专门分析各个数据源，用户请求涉及到数据源（各种服务的日志），理解日志的格式，然后做JOIN,把这些分布在各个数据源的行为日志重新构成一个完整的用户请求行为。绝大多数用户行为相关的标签，都需要根据用户行为日志来计算。所以这会是一个无法避免的问题。从根本上来说，SOA架构需要考虑实现统一用户日志的机制，统一日志格式，合并不同数据源的日志用于后续分析。但这非一日之功。而且很多公司并没有认识到统一用户

4、日志的重要性。因为开发和分析是有矛盾的，如果想要分析人员过的爽，开发人员的活就重一些；如果想要开发人员过的爽，分析人员就累一些。这是平衡的问题。而一般的公司都优先于系统功能的开发，分析的功能优先级低。（很不幸，个性化标签系统常常被归类成分析系统）对策：如果没有现成的统一用户日志，需要仔细评估自己实现合并不同数据源的行为日志的工作量，然后伺机而动。无非三种：不做，做，被强迫做。关键是“被强迫做”时，你如何控制风险？2.11.计算任务有次序依赖关系难点：部分标签是依赖基础表或其它标签的计算结果来计算。所以它们的计算必须要等到基础表和其它标签算完了，才能执行。对策：需要设计和实现一个计算任务的调度系统来解决这个问题。3.写在后面的话其实第二章的内容都是在做一些架构决策。其实架构设计的写法一直有两个流派，一派认为架构决策就是架构设计的内容，另一派认为架构设计应该要划分系统边界、模块、交互等。然