当数据变得庞大需要进行重构时，微服务该如何拆分

前言

前面分享了一个微服务的概念了解，微服务，也称为微服务架构，是一种架构风格，它将应用程序构建为服务的集合。集合里的每个服务具有高度可维护和可测试、松耦合效果、围绕业务能力组织，由一个小团队拥有。

总所周知，微服务架构是一种架构风格，所谓的架构风格就是一种抽象的结构，它由软件的各个组成部分和这些部分之间的依赖构成。或许看着概念有些抽象，但只要记住任何涉及抽象的设计，它的目的都是为了很好地适应大型业务应用，构建一个稳健的系统。

作为开发者就深有体会，一个应用初次开发完成了并不是真正的完成，它会伴随着时间或者用户的需求而不断的更迭，随着时间更迭就会存在人员因素和历史系统设计的局限性，日常维护糟糕且不稳定的系统一定会让人崩溃吧。这是每一位开发者都需考虑和面临的问题。

▲图/ 微服务架构策略图，橙色为当前内容

微服务拆分策略

首先，我们需要考虑的是共享类库的角色，也就是我们在开发过程中，习惯把一些通用的功能（帮助类）打包成一个公共类库或者包中。其他服务需要使用直接引用调用即可，增加代码的复用性。但是很可能存在隐患，这个公共类库不断地叠加导致出错或者版本问题会影响到其他服务。

更好的做法就是努力使得这个共享库都是一些不太可能改变的功能，同时由专门的人去维护而不是人人都去更迭它。或者是把这些可能会变更的通用功能作为一个服务来实现，而不是共享库。

其次࿰