到目前为止,天气预报系统已经初具规模了。我们不但实现了天气数据的采集,还实现了数据的缓存、天气数据的API服务及天气预报UI界面等功能。天气预报系统就是一个大而全的单块架构系统,里面混杂了太多的功能,可以预见的是,如果越往后发展,则系统会变得越来越难以管理和维护。同时不同服务之间存在着依赖,对于测试也是一个挑战。对于这样的系统,为了更好地实现可维护性、可扩展性,需要进行微服务改造。
本节所介绍的天气预报系统,正好是作为微服务架构改造的很好的案例。
在micro-weather-report应用的基础上,我们将对其进行逐步的拆分,最终形成独立自治的微服务。
我们要对天气预报系统进行微服务的改造。在经过一场头脑风暴之后,迅速将我们的期望和需求记录下来。
….
最后的省略号代表了这个需求是未完的。我们可以在改造系统的过程中不断去完善系统架构,这也符合软件开发的特征。但就目前而言,我们认为最重要的就是这些需求。
如果你熟悉DDD,那么很容易就能够从系统的限界上下文中,提取出我们的微服务。图7-1展示了限界上下文与微服务之间的映射关系。
整个系统可以分为天气数据采集微服务、天气数据API微服务、城市数据API微服务、天气预报微服务4个微服务。其中每个微服务又可以由不同的组件组成,其中:
对于代码而言,每个微服务都是一个独立的工程(应用)。针对上述拆分的4个微服务,代码可以分为如下4个工程。
数据是驱动系统发展的核心,了解系统的数据流向非常重要。
天气预报系统的数据,最初是来自第三方系统。这些第三方系统可以是国家气象局,也可以是其他专业天气数据服务网站。本书所采用的天气数据接口,都是来自互联网上免费测试用的接口,仅用于学习。
为了避免对第三方的数据接口产生冲击,我们需要限制下调用的次数。另外,我们还采用了Redis缓存服务器对数据进行存储,这样一方面可以减少直接调用第三方接口的次数;另一方面,可以有效提升天气预报系统的并发访问量。
图7-2展示了整个系统的数据流向。其中,为了提高系统的整体可用性,微服务可以水平扩展为多个实例。
天气数据API微服务对于调用方而言,大致分为两种。一种是提供给天气预报微服务作为天气数据的来源;另一种是直接提供给客户端来调用。
天气数据的采集依赖于城市数据API微服务,因为天气数据采集是根据城市ID列表来进行遍历的。同时,天气预报微服务也是依赖于城市数据API微服务的。
了解了数据流向之后,我们就能开始对系统之间的通信方式进行设计。
我们首先采用基于HTTP的RESTfulAPI的方式来进行系统之间的调用。RESTful API具有平台无关性,其数据格式可以很好地被开发人员所理解。
这些API大致分为以下几种。
*调用方式:GET http://wthrcdn.etouch.cn/weather_mini?citykey={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的文档格式,就能非常方便地实现城市数据的存储和读取。
本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。