为什么要做Thor？

360搜索有多个团队，几百号人。每个团队各自有多个平台工具，但各团队各自为战，带来的问题是没有统一的开发、管理规范，不论是交接还是扩展，做的人都很痛苦。当老人离开，新人接手会掉入无尽的坑中

Thor的目标

重新定义工具&平台该如何优雅的开发和产生

简洁、快速地将现有的平台工具集成进来

以工厂化的思维，让平台能产生平台，不再为了同类需求造轮子

简略架构

从Web端发起请求到Gateway，Gateway做一系列校验和处理后请求底层微服务；底层微服务提供服务，再由Gateway 返回响应。

什么是微服务？

其实最近两年微服务这个概念挺火的，那其实究竟什么是微服务呢？

微服务其实是一种架构风格、一种约定。就和我们开发中使用的设计模式是一个道理。
每个微服务仅关注于完成一件任务
每个微服务独立部署，互不干预
一个应用由一个或多个微服务组成

把我们上一文中的单体架构，拆分成微服务的结构，那么应该是如下图：

这里我们将每个功能拆分为一个单独的服务，有自己的web容器，然后通过gateway连结起来，对外提供服务。用户只和Gateway打交道，有点像是反向代理的感觉。

但这里的拆分并不一定非得变为这样，你可以拆得更细，或者是更粗，视你业务情况而定，不要脱离业务谈架构

单体架构

单体架构是最常见的架构方式，将所有功能、业务逻辑都放在一个web容器中，成为一个应用。这就是我们常说的单体架构。

例如，我们有一个小型商城系统，那么如下图所示：

在这里，我们将所有的功能都放在一个web容器中，例如订单管理、商品管理、支付功能、通知功能、购物车管理、物流相关等。

最近接触了一个有趣的需求：给定变量a、b、c、d等若干，要求由用户输入的普通四则运算字符串（包含加减乘除括号），算出具体的值。

例如，a=1，b=2，c=3，d=4，给出 a+b/(d-c)，应计算出结果为3，若为 a*b/(c-1) 则应计算出结果为1

这种情况下，第一反应可能是用数字值将字符串里的变量替换，然后通过eval()执行。或者是将字符串中的每一项通过正则一个一个扣出来再进行计算。

但这样的逻辑太粗暴，代码也太丑陋，其实大可不必如此。 此时，让我们将目光移向美丽的数据结构与算法。

我们在开发、维护的过程中，有时会需要将log、数据等做过滤和筛选

例如，我们有这样一个文件 daily_pv.txt ，它可能有10W行，其部分内容如下：

20170702    a    52331
20170703    a    63210
20170701    b    234213
20170703    b    341000
20170701    a    52103
20170702    b    233333

三列数据 分别对应了日期、地区标识、PV。此时我们可能需要将其按照时间排序，或是按照PV排序，方便我们进行分析。

很多时候我们的第一反应是写一小段代码，将文件读取到内存中，做排序然后再输出。这个方法是很好，但是比较费时，而我们使用一条shell命令就可以搞定。

但我们应该如何写呢？