我的spring cloud项目历程（2018.3~2018.9）

前言

今天是9月17日，趁着山竹的临幸，得以在家里舒适的办公。项目从3月底开始，至今刚好半年。抽几十分钟，总结下半年的历程。对后面的项目，应该也有一点帮助吧。

学习前的七个问题

项目开始前，由于某些特殊的原因，对spring cloud一无所知（甚至听都没听过，希望这种情况今后不再出现），所以我用手机的markdown软件Lite马上记录了7个疑问。我相信，不知道多少天后，这些疑问看起来将多么的可笑，呵呵。

1. 这是一个什么样的技术框架，用来做什么的
   
2. 和他相似的还有什么？各自优劣势？从什么框架发展而来？是否有后续新框架？
   
3. 如何使用？
   
4. 如何搭建
   
5. 和spring什么关系？和springmvc什么关系？
   6.什么样的系统应该用它？什么不应该用？
   
6. 最常用功能是哪些

定一个目标（学习后）

项目结束后，检查学会了哪些问题。

学习过程

• 3月19号星期一开始，到今天4月15号，已经四个星期了，即是一个月了。
• 4.30，发现很多疑问，特别架构上。
• 7.22，基本没有什么疑问了，就是有一些报错不知道怎么解决。

时间过得真快

4.30总结一些问题

微服务

• 一个系统怎么划分模块？也就是怎么划分server？
• 怎么划分一个服务？也就是rest api？
• 唯一流水号怎么生成
• 分布式事务怎么实现？还是说同一个事务的代码都写在一个服务里？
• 和领域驱动开发有什么关系或者联系
• 内部是否需要一个客户端，进行连接贯穿几个服务的处理，然后再提供rest给外部调用

Spring cloud

• 内部调用服务，eureka轮询的机制是啥？
• 效率如何？与直接调用本地方法差多少？
• @Transactional加在controller还是service
• 服务调用超时的话如何进行处理，会不会导致整个服务都用不了？
• 是不是应该一个外部接口一个容器？还是说同一个外围系统的接口都放在一个容器？还是说可以将所有的外部接口都放在一个容器
• 同一个方法被不同的模块共用，应该怎么处理

代码

• base64
• Uuid
• @Transactional
• threadlocal
• spring cloud代码目录结构
• Spring boot代码目录结构
• 是否需要vo、dto、bo、do、po
• 是否需要一个贯穿流程的类
• 逻辑写在数据库语句好还是写在代码里好
• 是否一个服务一个类， service dao都分开
• dao mapper什么区别

7.22总结一些问题

• 前面两大类的问题基本解决，第三类最后一来代码的问题的确有一些疑问还没有解决还不知道。
• 连接重置报错怎么解决
• 连接没有http返回报错怎么解决
• 数据库连接失败报错怎么解决
• 任务调度，批处理应该用什么，怎么写
• 令牌应该怎么生成

9.17解答问题

概念问题

1. 这是一个什么样的技术框架，用来做什么的
   • 微服务框架，用来提供微服务框架的常用功能，包括服务注册、服务网关、分布式配置等。
2. 和他相似的还有什么？各自优劣势？从什么框架发展而来？是否有后续新框架？
   • 相似的有dubbo、kibernate等。
   • dubbo用rpc，快一点，但不怎么更新；kibernate大而全，但好像与开源社区比较远离。
   • 基于springboot开发，集成了很快框架，包括Netflix里的eureka、ribbon、zuul等，spring自己也弄了很多，网关后面也不用zuul了，用自己的spring cloud gateway。
3. 如何使用？
   • 对于业务开发者，就是开发restful api，开发业务，写controller、service、dao，与平常使用springboot开发没什么区别。有一些小区别可能就是要学一下Feign怎么调用、怎么读取config的配置（其实也是用spring的特性来读取），但是遇到难题，就需要对spring cloud有深入了解了。
   • 对于搭建框架的，需要搭建zuul、config、eureka这些基本的，如果有需要，还需要看情况搭建zipkin、oauth2、elk
4. 如何搭建
   • 搭建其实需要写的代码很少，主要是配置pom，引入相关的starter，然后配置application或者Bootstrap文件。
5. 和spring什么关系？和springmvc什么关系？
   • 基于springboot，但其实springboot并没有太多东西，只是弄了一堆starter简化开发，内嵌了servlet容器等等。开发代码其实主要还是要懂spring开发，@RestController、@Configuration、@Bean、@GetMapping、@Transactional、@RestTemplate、@ComponentScan、@Retryalbe、@Cacheable等等这些技术，其实还是spring的技术。
     6.什么样的系统应该用它？什么不应该用？
     
   • 需要用到微服务的，都可以用它。那什么系统需要微服务？这是一个大话题，只要不是很小的系统，而又不想做成庞大的单体应用，希望可以降低运维难度的，都可以考虑使用。
   • 太小的系统，没必要用。已经运行的好好的单体系统，没有迁移的钱，也不要用。喜欢weblogic、jboss这些商用软件，不喜欢开源的也不要用（现在这种观点越来越少了把）。不是微服务的，也不要用，比如要做页面展示。不是企业级应用的，可能也不适合，比如要做一个压缩软件。
6. 最常用功能是哪些
   • 服务注册、分布式配置、api网关这三个是必须的。如果这三个都不用，也没必要用啥springcloud了。不是太简单的链路，sleuth也是需要的。安全、feign那些看需要吧。如果搞企业级，task、batch那些也可能用到。毕竟后台处理大量数据。

用了之后的问题

• 一个系统怎么划分模块？也就是怎么划分server？
  • 按领域划分。但其实很难，最简单可以按数据库划分。
• 怎么划分一个服务？也就是rest api？
  • 一个server-service是一个微服务。微服务里很多RESTful的api，只要可以封装为对外或者对内调用的一个完整的功能的都可以是一个api。但考虑到事务，也不要操作一张表就一定弄成一个api。
• 唯一流水号怎么生成
  • 分布式中，最简单的用uuid
  • 但uuid很长，很乱，无序，不好看，不好查，很多缺点
  • 最好还是搭建一个生成器，需要依赖mongodb或者redis这些分布式nosql
• 分布式事务怎么实现？还是说同一个事务的代码都写在一个服务里？
  • 没有现成的成熟框架，目前。不像oracle、tuxedo有xa等事务机制。
  • 一般同一个事务写在一个服务，但涉及多个数据库，需要通过自己写代码或者公司写一个框架封装保证最终事务一致性。
• 和领域驱动开发有什么关系或者联系
  • 很有关系。但大部分同事不懂，也很难落实，在国内目前。
• 内部是否需要一个客户端，进行连接贯穿几个服务的处理，然后再提供rest给外部调用
  • 这确实是一个不错的方案。client对外提供api，server端对内提供。

继续关于Spring cloud的。

• 内部调用服务，eureka轮询的机制是啥？
  • 有很多种，可以配置。原理是用了ribbon的机制，默认是轮询（round）
• 效率如何？与直接调用本地方法差多少？
  • 不经过网关，效率还是可以的。但毕竟跨了主机，淡然是调用本地的方法快一点，但分布式嘛，这点损耗可以接收。
• @Transactional加在controller还是service
  • 99%的书都是建议在service，但是引起的问题的需要维护的开发人员非常小心修改前人的代码
  • 不像之前用商用软件，可以随便改，都是保证在一个事务
  • 但微服务嘛，本来就应该简单，既然简单的，事务也不会太复杂
• 服务调用超时的话如何进行处理，会不会导致整个服务都用不了？
  • zuul和spring都有Retryalbe机制
  • 预防雪崩的话，spring cloud有熔断机制，可配置熔断规则。
• 是不是应该一个外部接口一个web容器？还是说同一个外围系统的接口都放在一个容器？还是说可以将所有的外部接口都放在一个容器
  • 其实这个问题很奇怪。一个容器肯定就是一个完整的微服务。
  • 掉不调用外围系统，只是系统内的一个功能，也就是一个service的一个方法，要调用几个外围系统，根本没有关系，所以也就没什么要放在单独的容器了
  • 如果怕调用过程中，超时导致tomcat默认的200个线程全部占满，完全可以启用熔断机制解决。
  • 如果为了解耦，确实可以单独出去一个微服务，比如是接口微服务，专门调外围系统，但是真的有必要吗？除非外围系统比较多，跟这个数据库又没什么关联的话。
• 同一个方法被不同的模块共用，应该怎么处理
  • 千万不要把代码拷贝过去！
  • 可以封装成rest，互相调用
  • 也可以封存成公用的jar，来调用
  • 如果只是1、2行代码，拷贝一下，也未尝不可
  • 如果以上三种方法都不合适，那要思考一下，你的模块划分是不是出了问题？