现实业务场景


  • 微服务框架的大行其道（SpringCloud、SpringCloud Alibaba），似乎没在微服务架构下写过代码都不好意思出去面试。
  • 在我最近待过的两家公司中，都采用了微服务架构，且研发团队没有超过20人，那酸爽，真够味。
  • 在前期业务不明确的情况下，为了赶上技术的新潮，毅然上微服务架构(似乎也不知道选什么)。

微服务架构爽吗


  • 存在即合理吧，在目前我看来，不过自己微服务用的确实不是很好。
  • 有的业务强制拆分成2个服务，在后期开发中发现其实就是一个业务，强拆灰飞烟灭。
  • 其实就是一个简单的查询，在业务中需要拉通很多服务进行调用，链路真的长，耦合度。。。
  • 跨库查询也是不太好处理的地方，当然我们用了最搓的方法（冗余），当然属于同步是个大问题

微服务需要面临的挑战

跨库查询

在微服务架构下，用户信息(特定的业务场景，真实名字、微信昵称等)被多个系统所调用，这个时候数据库怎么设计，服务如何交互。


  • 最简单的：冗余。 缺点：如果主系统发生改变，所有子系统如何同步问题
  • 提前准备的：提前同步到子系统。 缺点：实时同步概率不大，定时异步同步处理，子系统实时性不高
  • 实时：多次调用，实时获取。缺点：量大效率不高
  • ​​参考信息​​

分布式事务

  • 本地简单事务到分布式多系统事务的转变

强一致解决方案：


  • 二阶段提交协议
  • 三阶段提交协议

最终一致解决方案

微服务-存在即合理

逻辑清晰


  • 这个特点是由微服务的单一职责的要求所带来的。一个仅负责一项很明确业务的微服务，在逻辑上肯定比一个复杂的系统更容易让人理解。
  • 逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。

简化部署


  • 在一个单块系统中，只要修改了一行代码，就需要对整个系统进行重新的构建、测试，然后将整个系统进行部署。而微服务则可以对一个微服务进行部署。
  • 这样带来的一个好处是，我们可以更频繁的去更改我们的软件，通过很低的集成成本，快速的发布新的功能。

可扩展


  • 应对系统业务增长的方法通常采用横向（Scale out）或纵向（Scale up）的方向进行扩展。分布式系统中通常要采用Scale out的方式进行扩展。因为不同的功能会面对不同的负荷变化，因此采用微服务的系统相对单块系统具备更好的可扩展性。
  • ​​参考文献​​

我的系统该上微服务吗


  • 微服务意味着系统的拆分，会引入大量的中间件来进行系统协作。
  • 在业务不明确，还在业务驱动系统的情况不建议上微服务。
  • 在系统运行一段时候后，业务趋于成熟，团队成员对业务熟知且知道各种坑的情况下再进行服务的拆分。
  • 直到能够识别出稳定逻辑后再进行微服务的拆分，从而避免因为边界不清而进行重划分所带来的返工
  • 离开业务的架构都是在耍流氓，而且是非常不要脸的那种。。。