物联网架构成长之路(16)-SpringCloud从入门到吹水

1.前言
　　Spring Cloud 现在比较流行，版本更新也是蛮快的，网上资料也是很多。很多参考网上资料就可以学到了。这里给个 http://blog.csdn.net/forezp/article/details/70148833

2.放弃
　　本来还想写一篇Spring Cloud 入门环境搭建的博客, 后来想了想,还是算了,网上资料一大堆.这里就不写了.

3.吹水
　　下面就简单聊聊天,吹吹水算了

 

2018.01.18 笔记

　　公司网速不行，在进行Maven项目以来更新，偷偷写一些经历。
　　现在开始学spring cloud。回想自己学习JavaWeb的经历吧，大学时代2013-2014年学了SSH框架(Struts+Spring+Hibernate),工作后2015-2016年，用了(SpringMVC+Spring+JDBC)开发了一个项目，2017年，用来(SpringMVC+Spring+Mybatis)框架开发一个项目。四年，眼看这JavaEE技术的变更，真是太快了，开发也变得越来越简单。
　　想起刚开始用SSH框架时，班里好多人跟着老师，或者跟着网上的教程来配置环境都是不成功的，而且报错也是奇奇怪怪的。好多人最后都是拿着一份可以运行的最简单版本源码，复制过去，改一下包名。哈哈哈。现在想想真是搞笑啊。
　　下面只做一些回忆，里面有些知识可能会记错。
　　当年用SSH框架时，每配置一个bean都要在一个xml里面配置一个<bean>还要指定包名，一些参数等。那时候还没有bean注解这种方式。然后工作后，要负责开发一个项目了，本来想沿用以前学的SSH框架，后来上网找了一些文章，做了简单的对比。发现用SpringMVC会比Struts方便，就决定采用SpringMVC了。至于第一个项目，用原始最简单的JDBC的原因，是那时候觉得Hibernate太麻烦，然后去配置mybatis，但是一直配置不成功。花了几天都不行，然后就觉得算了，直接用JDBC，反正项目不大，内部项目，自己玩玩而已。
　　加上但是技术觉悟不高，JDBC连接，还是最原始的使用原生操作，每个请求一个Connect，创建Statement，然后处理完就关闭。连个数据库连接池都没有。性能特别差。但是这个内部的小项目，也就2-3个人在使用而已。完全没有问题。虽然后面出现了一点点性能问题。但是多等几秒就好了。也就不怎么管了。
　　线上出现过由于Connect没有即时关闭，导致tcp timewait问题，也简单的规避掉了，人生第一个用于实际生产线上的JavaWeb项目。就这样成功的运行着1年多了。
　　前半年对该系统进行了重构，技术框架也使用上了SSM框架了。第一次使用，用起来也还是比较方便的，印象最深刻的是bean的注入。但是前期项目的一堆XML配置还是少不了，不过就是项目初始化配置一次就可以，同时没有用Maven管理jar包，自己上网找jar包，然后放到lib目录下。一切都是那么的原始。
　　项目也没有进行什么单元测试。一套我看起来还算稍微复杂的系统，我自己写代码，自己简单的跑一下流程，没有经过任何专业的测试，然后就直接上线，直接使用。想想真是心大啊。如果出现问题，还真是麻烦。
　　小问题可以不断，大问题绝对没有。这个是我对我自己的要求。由于自己性格处事比较谨慎，加上有ACM竞赛背景。我自认为在同领域，同级别的同事间我代码实现能力是最快，出问题最少的人。
　　2018年，开始着手于新的项目，趁着微服务比较火，加上也挺适合公司用的，就准备在公司进行推广。这个推广应该难度不大，反正就我一个人，暂时也没有其他人要合作，同时没有历史遗留的项目问题，可以一步到位直接上SpringCloud。

2018.02.08 笔记

　　系统采用微服务架构, 目前搭建XX云平台基础服务,目前计划的基础服务有
　　　　1. XX开发者中心 (是对开发商进行统一管理,包含开发商认证,帐号分配,资源申请,固件上传等)
　　　　2. 设备统一认证中心(是公司对每一台设备进行管理,包含profile烧写及记录,设备日志等功能)
　　　　3. 用户统一认证中心(是对用户进行管理,包含用户手机注册,管理,微信/QQ/微博等互联,用户社交互动,对设备进行控制等功能)
　　　　4. 第三方资源服务 (外部服务对接,微信服务器,客户资源服务器,并对资源进行调度,流量控制管理)
　　　　5. 消息推送服务 (统一推送平台,推送到android/iOS手机平台,推送到微信公众号,小程序,推送到Web,手机推送, 小机设备推送等)
　　　　6. MQTT通信服务 (所有物联网产品,物物通信采用MQTT集群通信服务)

　　每个服务间的职责都是清晰分开管理.减少业务耦合度. 现在处于架构搭建初期,很多基础设施和业务都不清晰,只能一步一步慢慢完善,争取整个架构搭建起来,然后进行架构重新调整.
　　服务与服务间是免认证, 后面增加 全局认证服务, 统一对各个服务进行权限认证.
　　服务与服务间的数据共享, 通过缓存/关系型数据库/消息队列/分布式文件系统/阿里云存储
　　建立在各个基础服务之上的有 全局配置中心,全局监控平台,全局调度平台,OAuth2.0权限认证,Eureka服务发现,服务熔断机制等服务完善云平台架构
　　依赖于各个基础服务的是解决方案,具体项目.

　　项目初期,尽量防止过渡设计,大而全.初期尽量在满足业务的情况下,慢慢迭代优化,任何系统都不可能一步到位.
　　快速建立原型是必须的,但是前期的服务分层和架构必须严格遵守,职责分明.