Dubbo 微服务调用时序图及微服务架构个人见解

微服务架构

随着互联网技术的发展，客户对于一个系统来说越来越重要。是否能够最大限度的满足客户，是否可以快速适应客户需求的变更，是决定一个互联网系统能否存活的关键所在。为了能够使系统快速迭代，满足需求的不断变化，互联网系统逐步演化出微服务，将之前难以更新的巨型应用拆分成了一个一个的组件应用，根据业务划分成多个服务，解决了需求更新，应用更新难的问题。同时在业务上划分出不同的领域，使应用的开发人员可以更好的控制整个互联网应用。

一个完整的应用有前台也有后台，需求变化前端就变化，前端变化后端就随之变化，前端只涉及到一切可视化的展示，更新迭代速度可以满足需求的变化，而后端就没有那么轻松了，对于数据上，应用上的更新，可能很多时候无法支撑需求的快速变更。这时候就出现了中台，中台介于前台和后台之间，它没有前台更新的频率快，但却可以快速满足需求的快速更新。可以说，领域驱动设计帮我们将整个系统的业务进行划分，通过组件对业务进行实现，而拆分成更小维度的业务群体构成了系统的中台。整个系统的运行，是客户的需求驱动了业务产生，领域的划定让业务产生细分的维度，细分的业务让服务组件的产生。

当客户需求发生变化时，我们可以通过中台的业务组合，快速的变更前台，从而快速的提供新需求所需要的业务服务。

微服务架构可以用一个流程表示：

客户--需求--业务--领域驱动设计--中台--组件