最近这几年， 微服务 已经成为了主流，个人的理解，微服务这个东西，固然是有它的优点，但是如果你用不好，就会成为灾难。想要用好微服务，就一定要注意一下三点。

一，什么样的系统适合做微服务

微服务这个东西固然好，但是并不是所有的系统都适合做微服务，现在很多人有这样一个心理，看到一款技术框架很流行，大家都在用，那我为了追求时髦，我一定也要在项目里用一下。这种心理要不得，一定要去评估这款新的框架但适不适合你的系统的，如果不适合，你就会得到适得其反的效果。作为微服务来讲，一般来说如果项目不是特别大，访问量也没有那么大，就千万不要去做微服务。只有说你的系统大到一定程度了，在一个项目里很难维护了，这时候你再去考虑去做微服务。

二，微服务要依据什么样的选择对系统做拆分

系统拆分原则，这个并没有在业界形成统一的标准，每个人都有自己的想法，在这里我只是说一下自己总结的一些看法

1.如果两个子系统之间，需要保证事务的强一致性，那你就不要去拆了，因为现在没有任何一种方案，能保证事务的强一致性的，即便是 阿里 的seta，也不能保证强一致性，我们只能保证它的最终一致性，尽最大努力去减小数据不一致的时间，如果允许数据可以短时间的不一致，没太大影响，就可以做拆分，如果说数据段时间的不一致，也会带来很大损失，那就不要去拆了。

2.避免任意两个系统之间，特别频繁的调用。我第一次在做微服务的时候，拆分出了一个权限系统，这个系统负责用户的登录，权限分配，权限验证和 session 等等，但是考虑到，一个用户登录成功的，塔操作的所有功能，都要去调用这个系统去做session验证和权限验证，这样不仅仅会影响效率，也会给这个系统带来很大压力。后来的解决方案是，我们还是拆分出了这个权限系统，只不过我们在做session验证和权限验证时，不会直接去调用这个系统，而是用 maven 把对应的jar包依赖过，做本地调用。

3.在保证上面两点的基础上，尽量按照单一职责的原则去拆分，做到低耦合，高内聚。

三， 分布式 事务如何处理

这个现在没有一种方案，能做到事务的强一致性，我们只能尽最大努力减少数据不一致的时间，来保证它的最终一致性，这个上网去查，能查到很多方案，什么两阶段提交，三阶段提交，写回滚代码，等等，但是在真实写代码的过程中，没人会这么做的，因为它不仅性能差，而且会增加很多工作量。现在比较成熟的做法是用阿里的seta框架，它的原理就是记录了一张日志表，当需要做数据回滚的时候，就根据这张日志表的数据去做回滚，但是如果回滚的时候出现了网络问题，或者出现了脏写，依然会回滚失败，这种情况就需要人工处理。这也就是我说的阿里么seata并不能百分之百的保证事务强一致性的原因。

这只是我对微服务的一些个人看法，大家有什么看法或建议，欢迎评论区留言讨论[微笑]