DIY主题讨论15：微服务

【DIY主题讨论15：微服务】

微服务的价值是什么？

微服务的价值个人觉得最核心的是“小”，将服务变小。

1. 服务变小，降低开发人员学习成本：对于一个庞大的单体应用，庞大的代码，复杂的架构往往会使开发者望而生畏。
2. 服务变小，降低修改代码的难度：代码量越大，特别是祖传代码越多，代码间关联性越多，因代码修改而引入的bug会越多，服务变小，也就意味着修复缺陷或者增加新功能受过去的影响会越小。
3. 服务变小，但是功能越专一，促进于团队的功能职责越加明确，不同团队独立开发，减少相互之间影响。
4. 服务变小，迭代更快，可以使用更加合适的技术来实现功能，并且因为变小而可以快速迭代甚至是重构，使项目不会被旧技术栈绑死。
5. 服务变小，多实例拓展与解决系统性能瓶颈可以更加具有针对性，服务器资源的利用率可以大大提升。
6. 服务变小，每个服务可以快速发版，快速迭代，持续集成持续部署成为可能。

你接触过的最佳微服务实践是什么？

当然微服务也不是银蛋，带来好处的同时也会带来一系列问题需要考虑。
首先业务需不需要拆，是否按标准微服务模式拆？对于流量非常小的特别是企业内部使用的系统就不要拆，微服务细粒度运维的不能再这个场景带来好处，但是可以先在服务变小这个方向做些努力，如进行较好的模块拆分，那么后期可以快速将模块改造为服务。改造的过程其实就是将Java方法的调用替换为远程调用，在模块的结构组织方面，建议将跨模块调用拎出来放到独立的包里，定义接口和实现类，方便后期通过替换实现类完成拆分。

前面初步提了服务拆分，服务拆分也是走向微服务至关重要的一环，业务的拆分一般是基于领域驱动的模式拆分业务的领域模型，从单体应用向微服务架构风格的应用，一定是要演进的，建议使用绞杀者模式，以最快的速度先将单体应用接入微服务系统，再逐步拆分功能，这里常用Sidecar设计模式，比如使用SpringCloudSidecar可以快速的将一个应用接入进微服务系统而不需要改动原有代码。

走向微服务一定要有稳定完善的基础设施层，提供可靠的如服务注册发现，流量控制，熔断，分布式事务，链路追踪，异常发现，动态配置等功能，以及完善的容器运维平台和CICD平台，这些基础设施是微服务快速的落地的重要的保障