【DIY主题讨论15:微服务】
微服务的价值是什么?
微服务的价值个人觉得最核心的是“小”,将服务变小。
- 服务变小,降低开发人员学习成本:对于一个庞大的单体应用,庞大的代码,复杂的架构往往会使开发者望而生畏。
- 服务变小,降低修改代码的难度:代码量越大,特别是祖传代码越多,代码间关联性越多,因代码修改而引入的bug会越多,服务变小,也就意味着修复缺陷或者增加新功能受过去的影响会越小。
- 服务变小,但是功能越专一,促进于团队的功能职责越加明确,不同团队独立开发,减少相互之间影响。
- 服务变小,迭代更快,可以使用更加合适的技术来实现功能,并且因为变小而可以快速迭代甚至是重构,使项目不会被旧技术栈绑死。
- 服务变小,多实例拓展与解决系统性能瓶颈可以更加具有针对性,服务器资源的利用率可以大大提升。
- 服务变小,每个服务可以快速发版,快速迭代,持续集成持续部署成为可能。
你接触过的最佳微服务实践是什么?
当然微服务也不是银蛋,带来好处的同时也会带来一系列问题需要考虑。
首先业务需不需要拆,是否按标准微服务模式拆?对于流量非常小的特别是企业内部使用的系统就不要拆,微服务细粒度运维的不能再这个场景带来好处,但是可以先在服务变小这个方向做些努力,如进行较好的模块拆分,那么后期可以快速将模块改造为服务。改造的过程其实就是将Java方法的调用替换为远程调用,在模块的结构组织方面,建议将跨模块调用拎出来放到独立的包里,定义接口和实现类,方便后期通过替换实现类完成拆分。
前面初步提了服务拆分,服务拆分也是走向微服务至关重要的一环,业务的拆分一般是基于领域驱动的模式拆分业务的领域模型,从单体应用向微服务架构风格的应用,一定是要演进的,建议使用绞杀者模式,以最快的速度先将单体应用接入微服务系统,再逐步拆分功能,这里常用Sidecar设计模式,比如使用SpringCloudSidecar可以快速的将一个应用接入进微服务系统而不需要改动原有代码。
走向微服务一定要有稳定完善的基础设施层,提供可靠的如服务注册发现,流量控制,熔断,分布式事务,链路追踪,异常发现,动态配置等功能,以及完善的容器运维平台和CICD平台,这些基础设施是微服务快速的落地的重要的保障