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 服务发现, 服务熔断机制等服务完善云平台架构
依赖于各个基础服务的是解决方案, 具体项目.
项目初期, 尽量防止过渡设计, 大而全. 初期尽量在满足业务的情况下, 慢慢迭代优化, 任何系统都不可能一步到位.
快速建立原型是必须的, 但是前期的服务分层和架构必须严格遵守, 职责分明.
来源: http://www.bubuko.com/infodetail-2494258.html