现实业务场景
微服务框架的大行其道（SpringCloud、SpringCloud Alibaba），似乎没在微服务架构下写过代码都不好意思出去面试。
在我最近待过的两家公司中，都采用了微服务架构，且研发团队没有超过20人，那酸爽，真够味。
在前期业务不明确的情况下，为了赶上技术的新潮，毅然上微服务架构(似乎也不知道选什么)。
微服务架构爽吗
存在即合理吧，在目前我看来，不过自己微服务用的确实不是很好。
有的业务强制拆分成2个服务，在后期开发中发现其实就是一个业务，强拆灰飞烟灭。
其实就是一个简单的查询，在业务中需要拉通很多服务进行调用，链路真的长，耦合度。。。
跨库查询也是不太好处理的地方，当然我们用了最搓的方法（冗余），当然属于同步是个大问题
微服务需要面临的挑战
跨库查询
在微服务架构下，用户信息(特定的业务场景，真实名字、微信昵称等)被多个系统所调用，这个时候数据库怎么设计，服务如何交互。
最简单的：冗余。 缺点：如果主系统发生改变，所有子系统如何同步问题
提前准备的：提前同步到子系统。 缺点：实时同步概率不大，定时异步同步处理，子系统实时性不高
实时：多次调用，实时获取。缺点：量大效率不高
参考信息
分布式事务
本地简单事务到分布式多系统事务的转变
强一致解决方案：
二阶段提交协议
三阶段提交协议
最终一致解决方案
TCC模式
补偿模式
可靠事件模式
参考文档，受益匪浅
微服务-存在即合理
逻辑清晰
这个特点是由微服务的单一职责的要求所带来的。一个仅负责一项很明确业务的微服务，在逻辑上肯定比一个复杂的系统更容易让人理解。
逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。
简化部署
在一个单块系统中，只要修改了一行代码，就需要对整个系统进行重新的构建、测试，然后将整个系统进行部署。而微服务则可以对一个微服务进行部署。
这样带来的一个好处是，我们可以更频繁的去更改我们的软件，通过很低的集成成本，快速的发布新的功能。
可扩展
应对系统业务增长的方法通常采用横向（Scale out）或纵向（Scale up）的方向进行扩展。分布式系统中通常要采用Scale out的方式进行扩展。因为不同的功能会面对不同的负荷变化，因此采用微服务的系统相对单块系统具备更好的可扩展性。
参考文献
我的系统该上微服务吗
微服务意味着系统的拆分，会引入大量的中间件来进行系统协作。
在业务不明确，还在业务驱动系统的情况不建议上微服务。
在系统运行一段时候后，业务趋于成熟，团队成员对业务熟知且知道各种坑的情况下再进行服务的拆分。
直到能够识别出稳定逻辑后再进行微服务的拆分，从而避免因为边界不清而进行重划分所带来的返工
离开业务的架构都是在耍流氓，而且是非常不要脸的那种。。。
