前言
虽然我觉得大部分项目或产品情况下，都是没有必要使用微服务这种重量级高复杂性的框架的，但还是有不少团队或多或少的使用了微服务技术框架，相信他们应该已经或是即将遇到很多的实践上的问题。这次就在这篇文章中，聊一下对于普通开发者在微服务框架下进行开发的一些注意事项。此外，本文仅针对java后端的开发人员哦。
最重要的一句话，在没有绝对必要或理由的情况下不要使用微服务。如果你已经用了微服务，那只能给你些个人血泪换来的建议和Goodluck。
适应范围
以下的注意事项或是建议均只适用于以下情况：
- 团队中至少有70%的人是第一次在微服务框架下进行开发
- 团队人数小于10人
- 团队可控的计算资源少于3台服务器
- 团队没有成熟的云平台服务可以使用
注意事项
开发相关的问题
- 接口服务提供者做好幂等性处理，这个一般可以在发送请求时做一个uuid，然后调用方收到请求后自动检查这个uuid看看是不是已经接受过这个请求了，具体方法可以在Http的header中进行添加，然后服务提供方通过AOP自动处理这个uuid；
- 接口调用者要做好自动多次尝试的准备，微服务框架中有不少会有自动重试的机制，比如SpringCloud的Ribbon，其中自然就会涉及到超时时间和最大重试次数等参数的选择，其中要根据业务特点来设定这些参数；
- 接口调用者要做好接口调用失败的准备，这里又分为多种情况了，一种是显示的报错，一种是过长的相应时间，这种要做好，超时限制而且要注意虽然你这边报超时错误了，但这个请求被调用方又成功处理了，所以如果你的调用方是个有状态的服务那这时候就可能出现状态不一致的问题；
- 能不使用事务的就不要使用事务，多个服务的事务处理严格来说只能依赖SEATA等分布式事务中间件来做，实现复杂度相当高。
- 避免循环中进行调用另一个服务，把信息集中在一起进行批量的查询和处理，比如类似于findById的操作，以前单体应用时问题不大，但如果是两个单独的服务，就涉及到网络传输的问题，而且微服务之间传输的信息都需要序列化和反序列化的操作，那么时间量级至少在50ms左右，只要一个循环超过100次那么这个单一的请求响应时间就查过5s，然后就可能导致上游的服务发生超时错误，又自动重试，从而产生雪崩式爆发。
基础设施相关的问题
在没有足够的基础设施的情况下，利用微服务进行开发，无异于在漆黑的道路上开车还不开车灯。在微服务框架下，出现问题是很难定位和复现的，问题的定位难度和复杂度都是与单体时代不再一个层级上，原因就是因为一个请求可能在多个服务，多个数据库乃至不同的服务器上跑，所以传统仅依靠日志来定位问题在微服务框架下就不够看了。要想拥有足够的基础设施，那么你需要两种资源：1. 足够的计算资源，就是服务器或是计算机，这些东西能让你有足够的设备来运行类似于promethuse，elk，skywalking之类的东西。2. 足够的人，你需要人员来搭建基础设施，进行相关系统的维护。
但是考虑到这两种资源在软件团队中都是稀缺资源，所以大部分团队在实施微服务改造时都会遇到基础设施不足的问题，所以我这边给出基础设施建设的优先级。
绝对少不了的当然是版本管理系统啦，推荐使用git，局域网直接搭建gitlab一步搞定。
- 注册中心，这个东西没有的话就不能成为微服务啊，所以你是肯定需要的，对于资源短缺的团队来说，多个项目共享注册中心是个好主意。
- 配置中心，这个东西呢，其实是需要的，但是实在是没有资源的话可以不要，所以nacos是个不错的 选择，注册中心与配置中心合一，当然你还是需要服务器来运行相应的数据存储。
- 日志聚合系统，典型就是ELK啦，其实这个东西一台服务器就可以搭建完成，其中logstash比较重，直接使用filebeat也是可以的
- 监控系统，典型的当然非Promethuse莫属了。配合各种exporter和Grafana很快就能搞出一套炫酷有实用的监控系统。
- 持续集成系统，典型产品就是jenkins啦，这个其实应该是必不可少的东西。
- 链路追踪系统，这个使用Skywalking就不错，功能强大，安装配置也很快
- 镜像中心，Habor最近两年取得了长足的进展，终于有了垃圾清理，再也不用担心空间被莫名其妙的吞掉了，所以在项目比较多的情况下搞一个自己的镜像中心是很不错的选择。
- 持续集成集群，当你的项目较多的时候就肯定要采用集群的方式来实现构建等工作啦，这个是值得投入的。
- 通用的elasticsearch，前面的很多服务都可以对接到es上，所以搞一个es的集群对你有很多益处
- PAAS集群，当然是已经成为事实基准的kubernetes啦，这个东西呢很复杂，但也颇为强大。
- IAAS 集群，这年头自己搞虚拟化的已经比较少了，所以不是很推荐，直接在物理机上安装linux再加入到kubernetes上就很不错。
10.ServiceMesh，这个要在前面的PAAS的基础上实现，适合拥有自家产品需要运维的团队。
其中前4条是非常推荐的，尤其第3-4条用了都说好。
结论
微服务本身没有任何错，关键是场景是否合适。
对了，如果你的团队可以使用云平台的各种服务，那你算是有福了，各种云平台都提供了一应俱全的基础设施，只需要你的公司付钱就好啦。
最后最后，使用微服务之前一定要三思。
