评估是否使用微服务架构的五个关键条件

​为了实施微服务架构，我们一直在遵循实践原则：每个微服务都必须拥有自己的独立数据库来避免数据库级别的耦合。

为了更好地解决特殊场景的问题，微服务架构不提倡使用适合所有场景的标准化技术，而是为了根据每个服务的特性选择更合适的技术。

当请求量增加时，只需要扩展一些服务而不是所有服务；同样，当数据库性能无法满足需求时，则仅需扩展和升级某些服务的数据库。

这也是微服务的架构的优势所在；《领域驱动设计》引入了上下文“ boundedcase”的概念，通过梳理业务来找到不同业务上下文之间的界限，帮助我们找到了划分小服务的方法，重点是业务边界。JamesLewis和MartinFowler在微服务的定义中还强调，微服务是基于业务能力的构建。

因此，评估公司是否需要使用微服务架构通常会检查这五个关键条件：

1. 数据量
2. 业务复杂度
3. 团队规模
4. 应对业务流量变化
5. 是否有足够的容错和灾难需求

Dobo是相对早期的微服务架构，可以使应用程序能够通过高性能RPC实现服务的输出和输入功能以及Spring框架无缝集成。

不同类型的应用程序可以通过微服务功能演变为现代应用。

​目前许多企业可能都面临着是否要将单体架构进行微服务升级改造的问题。但从一个大一统的系统，拆分成一个一个单独的小服务，企业需要投入的人力、物力、财力是非常巨大的。在没有足够的资源投入之前，不妨选择一些折中的方案。

传统架构的最大问题就是紧耦合，在应用迭代、升级的过程中，除了升级微服务架构之外，选择一些可插拔式的技术工具也可以很好的解决问题。比如：FinClip小程序容器技术 ，这是一种以小程序技术为载体，发展成组装式的企业应用架构技术。

从应用层来说，只要把FinClip SDK嵌入到企业的App中，就能立刻获得小程序运行能力。不管你的项目是什么软件架构，都可以通过这种嵌入式的小程序技术去获得APP并行开发、热更新、敏捷迭代的能力。

从开发角度来说，这是一种「Native + 小程序」的混合开发模式，借助这种模式可以让小程序运行在自有 App 中，将臃肿的 App 功能打散，功能模块互相解耦实现模块化开发，各业务模块间互不影响，通过管理后台即能实现实时动态更新与发布。对于一些积重难返的项目来说，采用这种入侵性小、可插拔式的技术是一种值得尝试的解决方案。

​