看文章标题，读者可能会觉得奇怪。微服务、分布式、单体，似乎每个词语都理解，可是这里怎么就这么违和的摆在了一起？
但是对于忍受过分布式单体架构的研发人员，应该马上就会心领神会。所谓分布式单体，就是技术形态上利用诸如SpringCloud技术栈，但是实际在业务层面上，仍旧把大量业务写在了某一个模块上。最终会发现整个项目的微服务架构，只是徒有其型。既没有达到微服务设计应该达到的效果，反而因为系统负责度的增加，对开发造成了诸多不便。
出于种种原因，可能是为了项目的技术创新点；可能是技术人员为了显示自己的架构设计能力；也可能是某了某些需求，在对旧的单体应用进行改造。最终将微服务架构引入了系统当中。于是我们看到了网关，看到了认证中心，以及若干个庞大的单体模块在这个微服务系统中。
微服务架构，当然有各种好处
1、每次运维更新时，更有针对性，不需要因为一处变更，而对整个项目进行打包构建；
2、往系统中引入新的技术栈更加方便；
3、减少了代码冲突的可能；
。。。。。。
但技术上带来好处的同时，也会增加管理上的复杂度
1、如果更新涉及到多个服务，就需要考虑到启动顺序的问题
2、分布式系统需要解决的固有复杂度，如：分布式事务问题、系统全局有序id生成策略等
如果我们的系统最终变成了微服务架构，但是业务代码还是集中在若干个模块中，模块之间还是强耦合的，一个挂了还是全局挂掉，开发效率也没有提升，那就该思考一下我们的微服务架构设计的必要性了。
微服务架构没有设计好，往往并不是技术问题。技术域的问题，往往都是有各种成型的解决方案的，我们要做的是明确我们的实际场景，选择一种合适的解决方案。更大的问题在于领域拆分。这个是非常依赖对于系统业务的了解的。如何将业务拆分得粗细得当。在做拆分的时候，尽可能减少同步调用。每个拆分后的微服务之间或得更低的耦合度。这样才能做到在不做优化的情况下，或得更少的分布式所带来的稳定性损失。而这个拆分的依据，往往是技术+业务双维度的。总之，这是一个非常具有实战性的活儿。有设计的方法论，但是怎么应用到具体项目中，往往并没有一个明晰的标准。只能根据最终结果，是否有利于开发效率、系统稳定性，来判断拆分的是否合理合适。
这里想表达的并不是微服务架构设计不好。而是见过太多系统，本身复杂度、性能要求、团队人员配备，并没有到达非用微服务的地步，盲目跟风，最终整出个四不像。
关于微服务在项目中的应用，个人体会有以下几点需要考虑
1、真的需要微服务才能满足系统的要求吗
2、团队成员是否具备用好微服务的技术能力
3、旧单体改造微服务的项目，数据库尽量别去动
4、除了明确的系统认证、日志等和业务关系不大的模块，可以单独一个微服务，其他涉及到频繁相互调用的，即使业务上不是两个业务领域的，如：订单系统和库存系统。也应该考虑是否将其归并到一个业务模块上
总之，微服务架构，慎用。
