标签：dao 获取天气 坚持 马克思 演进 微服务 风格 资料 present
简单介绍一下四个模块分别的作用：
城市信息模块：
主要是调用第三方服务获取所有的城市信息，用于数据采集的时候调用
数据采集模块：
由于是基于调用第三方 api 的服务，所以我们要考虑到服务的可用性：比如网络的原因，网络因素的不可控的，每次调用都都可能出现各种网络的问题：网络连接超时、甚至连接不上，延迟太大等。所以我们应该避免多次的远程网络的服务调用。同时是基于第三方服务，可能有服务调用次数限制等原因，结合我们项目的需求，可以将数据定时采集缓存起来。因为天气信息在一段时间内是变化不大。所以我们采用定时任务的形式，每30分钟将城市信息对应的天气信息缓存起来。
还有这里，根本不需要存储太多的额外数据，最多就是一个城市数据，基于城市数据动态变化的可能性太小，我们采取 xml 的形式存储即可。最后基于 javax.xml.* 包下解析即可。方便快捷。减少数据库的维护成本。
所以，一切的技术选型都是基于业务需求去考虑的，当然前提是你得会这门技术，要不只能退而求其次。
天气数据模块：
主要是获取天气数据信息。根据城市的 id 或者 城市的名字 从缓存中获取数据信息。
天气预报模块：
响应对应城市的最近一周天气信息。
总而言之，整个系统不是很大，就四个模块，每个模块的功能也不是很多。但是每个模块有分工明确。所以比较适合进行初级的服务划分学习。
其实简单的可以理解为，单体架构就是从开发到部署，所以开发人员都是针对一个项目进行开发，最后基于这个项目部署到服务器上的。简单来说就是所以功能都集中在一个项目中进行开发部署。而我们上面的天气预报项目就是一个单体的架构。
这种架构也是有很多优点的，因为，我们都是这么过来的。所以他很简单。
那从几个方面来体现他的简单呢？
学习简单：容易学习，上手简单。毕竟我们都是这么过来的。
部署简单：直接一个 war 包，部署到 tomcat 中即可。
层次简单：就是 dao -> service -> web 这样开发即可。
技术简单：也不能说是技术简单吧，应该说是技术单一。spring、Mybatis就可以基本搞定。
等等。
那说完它的优点，它的缺点呢？其实它的缺点是针对于中大型的互联网项目来说的。由于中大型互联网项目的特点：项目业务复杂、开发人员众多、项目迭代周期短。基于这些特点，我们很容易就能从单体架构中发现其不足。但是要记住一点就是，不是一说大型互联网项目就是高并发、高可用这些看起来高大上但是其实但臃肿的词语来概括。不要高并发、高可用中毒。一切都是根据项目的情况出发。所以说，我们所谓的单体应用它的缺点是在一个项目业务复杂、开发人员众多、项目迭代周期短的情况下才体现出来的。但是单体应用还是最基础的。如果你坚持到最后，你会发现最后还是会回归到类单体应用上来。那就是单元化架构（SET架构）。
好了，哔哔了这么多，我们回归正题，来说说单体架构的缺点。
代码维护困难：所有人都是基于一个项目在进行开发，可能会出现代码冲突等情况。更重要的是，代码的安全性不高。可想而知。我们要基于单体架构开发，我们就能拿到所有代码，这在大型互联网公司中是不可想象的。实际上，我们只需拿到我们负责的那个模块的代码即可。或者与该模块关联的代码。其他代码我们都是没有的。这也有利保护公司的利益。
项目迭代困难：现在的互联网项目，更新迭代太快，三天一个小版本，一周一个大版本，也是很正常。这么频繁的迭代周期在单体架构中是不可能实现的。因为我们版本迭代不可能像单体架构那样把整个项目下线更新之后再重新上线。这样三天两头上下线，切合实际吗？显然是不可能的。
复杂的业务需求应对有些吃力：现在很多互联网公司都是有很多相关的项目的。比如百度的百度文档、百度网盘、百度知道。。。等等。业务形式多种多样。如果在一个单体的架构中代码太过庞大。这个是难以想象的。
最后在补充几点：交付周期长、可伸缩性差、监控困难、等。
基于单体架构上面的缺点，我们需要对项目的架构进行改进，来增加项目的稳定性和可扩展性等。如何一个人买菜、煮饭、炒菜。全家人吃饭，凭什么我一个买菜、煮饭、炒菜啊！所以我们多个人来，你买菜、我煮饭、他炒菜。快捷简单又不累。项目也是这样，像单体架构那样，服务器太累！所以请求都是它一个人扛，一个人处理。我已得将项目拆分开来。分别部署在多台服务器上。这就是分布式架构。
集群与分布式是息息相关的，因为他们都是为了达到高可用的目的。
那什么是集群呢？
简单理解，就是洗碗那样。比如大过年，亲朋好友来得特别多，吃完饭，碗筷也就是多咯，那一个人来洗的，太累，那就多个人来洗不就行了吗。
这就是集群的概念：多个人，干同一件事。也就是说，多台服务器，每台服务器处理的业务都是一样的。而分布式，多个人分开来，来完成一件事。
项目拆分是分布式架构最重要的一环。当然，也不可能一下子就能拆分得很完美，这些都是与你的项目经验、业务能力息息相关的。我们只能做到尽可能的准，尽可能接近完美。
那我们怎么去拆分呢?
业界早已有许多大牛总结了很多经验，我们可以参考学习，指导我们。最后结合我们的业务需求进行项目拆分。
比如项目拆分的时候需要考虑哪些问题？需要遵循哪些原则？需要注意哪些点？这些我们都能从大牛哪里吸收经验。
由于我们的项目业务比较简单，很多拆分的规则都体现不出来，如下图
? 注：每个白色的框框都是一个项目，单独部署在一台服务器上的项目，然后又有集群。其实应用层也是可以集群的。比如：
所以从上面的图中我们可以简单的了解了一下什么是分布式的架构。那同样也面面临着许多问题。
比如：分布式session、不同项目之间如何通信、集群中数据一致性、分布式安全、事务、负载均衡等。很多问题。这些问题现在已经有了很好的解决方案。我们这里不再赘述。我们主要是讲springcloud实现的微服务。这里只是简单了解一下分布式，和分布式架构的基础模型。
如果说什么是微服务？我们只能理解为是这样的，微服务是粒度更小的分布式，但它还是分布式。
上面这一点很重要，有人会以为，微服务是一种全新的架构，比分布式更吊的架构，其实不然，只是对比于传统的分布式架构粒度更小。这是我个人的理解。
下面我们谈谈几个简单、但是又很重要的概念：
SOA： Service - Oriented - Architecture 面向服务的体系架构
你可以简单理解为它是一种规范，架构设计的指导思想。就像马克思主义指导我们天天向上。是一个好的开发指导原则。
主要包括以下几个原则：
服务的契约
服务的可组合性
服务的无状态
服务的可被发现
服务自治
等原则。
简单理解就是，能够对外提供特定的服务，每个消费该服务的消费者对于该服务是透明的，消费者只需调用服务即可，不需要关心服务内部的运转。同时该服务可以调用其他基础的服务组成。
上面只是简单理解，在我个人理解的程度更加白话的方式书写，所以在这里只需了解这是什么就可以
下面我们讲讲实现SOA的几种常见但是有古老的存在：注意下面也是一种规范，只不过是根据SOA设计出来的
好，我们就将这些比较常见的概念讲到这里，如果你还想了解JMI、EJB等。可以自行找资料学习。
但是请注意SOA不是微服务，它跟微服务还是有很大的区别的。
-- 这个先讲到这里。。
标签：dao 获取天气 坚持 马克思 演进 微服务 风格 资料 present
原文地址：https://www.cnblogs.com/Hunter-1/p/9795184.html
