一郎科技|大牛带你实时解读微服务架构改造案例：天气预报系统的架构设计( 二 ) 天气预报系统的架构设计到目前为止

天气数据API微服务对于调用方而言，大致分为两种。一种是提供给天气预报微服务作为天气数据的来源;另一种是直接提供给客户端来调用。
天气数据的采集依赖于城市数据API微服务，因为天气数据采集是根据城市ID列表来进行遍历的。同时，天气预报微服务也是依赖于城市数据API微服务的。
系统的通信设计了解了数据流向之后，我们就能开始对系统之间的通信方式进行设计。
我们首先采用基于HTTP的RESTfulAPI的方式来进行系统之间的调用。 RESTful API具有平台无关性，其数据格式可以很好地被开发人员所理解。
这些API大致分为以下几种。

第三方天气接口。

*调用方式:GET {cityId} 。
*参数:cityId为城市ID 。

天气数据接口。

*调用方式:GET /weatherlcityld/ {cityld} 。
*参数:cityId为城市ID 。
*调用方式:GET /weather/cityName/{cityName} 。
*参数:cityName为城市名称。

天气预报接口。

*调用方式:GET/report/cityId/ {cityId} 。
*参数:cityId为城市ID 。

城市数据接口。

*调用方式:GET/cities 。
*参数:无。
系统的存储设计我们的系统并没有采用传统的关系型数据库，如MySQL、Oracle、SQL Server等，而是采用了NoSQL的方式（本书采用了Redis )。
对于经常需要访问的数据，放置在Redis缓存中可以极大地提升并发能力。同时， Redis由于都是在内存中操作，插入或更新的数据速度会非常快，非常适合我们系统的应用场景。
另外一些数据，比如城市信息，都是常年不会变更的数据——有时，这些数据也称为静态数据或码表数据——那么这类数据就可以简单地用一个文件来进行存储，例如，本文采用XML的文档格式，就能非常方便地实现城市数据的存储和读取。
本文给大家讲解的内容是天气预报系统的架构设计