前言
前面分享了一个微服务的概念了解,微服务,也称为微服务架构,是一种架构风格,它将应用程序构建为服务的集合。集合里的每个服务具有高度可维护和可测试、松耦合效果、围绕业务能力组织,由一个小团队拥有。
总所周知,微服务架构是一种架构风格,所谓的架构风格就是一种抽象的结构,它由软件的各个组成部分和这些部分之间的依赖构成。或许看着概念有些抽象,但只要记住任何涉及抽象的设计,它的目的都是为了很好地适应大型业务应用,构建一个稳健的系统。
作为开发者就深有体会,一个应用初次开发完成了并不是真正的完成,它会伴随着时间或者用户的需求而不断的更迭,随着时间更迭就会存在人员因素和历史系统设计的局限性,日常维护糟糕且不稳定的系统一定会让人崩溃吧。这是每一位开发者都需考虑和面临的问题。
▲图/ 微服务架构策略图,橙色为当前内容
微服务拆分策略
首先,我们需要考虑的是共享类库的角色,也就是我们在开发过程中,习惯把一些通用的功能(帮助类)打包成一个公共类库或者包中。其他服务需要使用直接引用调用即可,增加代码的复用性。但是很可能存在隐患,这个公共类库不断地叠加导致出错或者版本问题会影响到其他服务。
更好的做法就是努力使得这个共享库都是一些不太可能改变的功能,同时由专门的人去维护而不是人人都去更迭它。或者是把这些可能会变更的通用功能作为一个服务来实现,而不是共享库。
其次