微服务2.0-开发逻辑架构和运行物理架构解耦

大家好，我是人月聊it。

在上周有一个朋友给我留言，希望我讲一下微服务2.0方面的内容，所以我特意到网上搜了一下，因为在原来我的印象里面是没有微服务2.0这个概念的，所以说搜索以后发现是2003年6月份，Google的一个工程师发表了一篇论文，就是提的是叫面向云的现代应用开发之路。

在这篇文章里面，他对微服务本身的优缺点做了进一步分析。对于微服务优点大家都知道，在传统的单体应用转成微服务以后，对于每一个微服务它本身的相应的性能扩展性都得到了大幅的提升，包括可以更好的解耦，更好应对软件需求的变更。

但是微服务架构本身也带来了很多的问题，比如说微服务和微服务之间的进程间通信带来的性能损耗，包括整体微服务应用整体的性能由于做了解耦导致的性下降。包括在传统单体做了微服务拆分以后整改微服务治理，后续的微服务应用可观测性和运维都变得相当复杂。

逻辑架构和物理架构解耦

所以说在这种情况下面，他就提出了一个关键的问题点，就是原来我们的微服务架构更加强调我在开发态的时候，我的逻辑架构和我在运行态的物理架构往往是一对一映射的，我在开发态的逻辑架构怎么分解的往往部署的时候物理架构也是相应的做了对应的分解，所以说他提出一个关键问题，这两者之间能不能更好的去解耦？

简单的来讲，就是我在开发设计的时候能不能更多的还是沿用单体架构的方式去设计，但是单体架构部署到云环境中以后，云环境中可以根据单个组件它本身的性能或者是扩展性的要求来进行拆分，将对于性能要求高的组件可以单独去剥离去进行部署去进行扩展。

也就是说我在开发的时候并不需要太多的去考虑你运行态怎么样去扩展，怎么样去做拆分，这个是他提出的一个关键思路。

所以后面他也做了一个关键的总结，就是当这两者进一步去做了分离以后，新的微服务架构模式能够将原有我们的整个应用的性能损耗下降15倍，我的整个应用开发的成本节约9倍。

所以为了更好理解这个话题，我后面结合谷歌的这篇文章，做了几页PPT，进一步给大家做一个简单的分享。跟大家进一步讲解一下微服务2.0的基础概念和核心关键技术要点。

微服务2.0的基础概念

在微服务2.0里面，它更加强调的就是叫逻辑边界和物理边界之间的一个解耦。在开发态的时候，程序员仍然是按业务逻辑编写整体应用，其中包含多个组件，组件和组件之间通过接口调用外部看起来一个整体。

所以说它把它叫做是叫逻辑单体应用。在运行态的时候运行时，环境负责决定每个组件的物理运行位置。

例如他可以选择将两个组件合并在一个进程中，也可以将单个组件部署在多个进程多台机器上，所以组件与微服务类似都是长期运行的服务实体，区别在于组件只规定了逻辑边界，但是微服务同时规定了逻辑边界和物理边界，运行时还包括负责处理组件的扩容、缩容、重启、高可用等各种底层的技术细节。

通过这种方式可以看到开发态它只关注逻辑边界，将应用分割为多个组件，而运行态会根据你的性能负载等各种条件决定物理的部署形式。

两者分工明确，开发者不需要关注运行细节，也不要将这些细节硬编码到应用程序里面。比如上面左边这个图，在应用开发的时候可以看到三个组件，我可能是作为一个完整的单体应用在开发，我只是有组件划分的方法。但是到了运行态，对于组件C它可能性能需求并发量比较大，那我可能是拆成了两个节点进行部署，但是对于组件A和组件B，它本身的扩展性要求没这么高，那A和B我完全可以部署到一个进程里面，而且是走进程内部的通信。

所以说到了右边这个图我们就可以更看得清楚。到了运行态的时候，组件和组件要不要拆分，完全是根据运行时的性能负载来决定的。如果组件要拆分，这个事情跟开发它也没有任何关系，同时到了运行态的时候，组件和组件之间就变成了进程间通信，所以说它上层增加了个一个信封Envelope。这个信封更多的是起一个守护进程，或者是类似于服务网格里面边车代理的作用，通过信封和它上层的全局管理器，可以更好的去实现伸缩容，实现相应的日志的跟踪、安全度量等各种相应的管控措施。

微服务开发和运行态拆分和动态绑定

所以结合这个我们再来分开理解就可以看到，对于传统我们讲的微服务架构，它的开发和运行态拆分往往是两者是一对一的。比如在我的开发态，我分了供应商微服务，订单微服务和库存微服务，那么到了运行态，这两者之间完全是这两者之间完全是一一对应的一个关系。我的供应商微服务那就会对应到我供应商的运行时，我的订单微服务我就会对应到我订单运行时，两者完全一对一。微服务是一对一映射，数据库也是一对一映射。所以说这种情况下，在我开发态的时候，我就必须去考虑怎么样去拆分和拆库，怎么样去进行分布式事务的一个处理。

微服务逻辑边界和物理边界解耦

因此微服务2.0更加强调的是什么？

即微服务应用的开发态逻辑边界和运行态物理边界能否更好的解耦？在应用的运行态根据并发和负荷情况自动进行拆分部署。但是在开发态的时候我可能仍然会按照一个大单体进行开发。即微服务虽然做了组件拆分，但是组件之间它好像仍然是走的内部接口；到了部署完成后的运行态，微服务需要根据应用的性能去进行拆分部署。因此在这个拆分部署的时候，在你相应的应用组件边界之间，它就会类似增加一个我们讲的叫rpc代理，这个代理是在运行态下云环境自动配置和下发下去的，你在开发态并不需要关心。

也就是说在开发态我可能是走的一个内部的方法或者是函数的调用，那么到了运行态，我能够自动的把它变成一个进程间的rpc远程调用，我唯一需要做的就是在开发态，我组件之间的接口，内部方法调用怎么样去做更好的设计。这个和原来我谈到过的微软的Dapr框架有一定的相似之处。但是Dapr框架并没有做到运行态的动态拆分部署能力。

对于微服务对应的数据库也是一样的道理，底层对应的数据库能不能做到在开发态我就是一个大的数据库SID，最多也就是我在同一个数据库实例里面分了多个Schema。在开发态的时候我能够做跨scheme查询的，我仍然可能是写的关联SQL的语句。那么这个时候到了应用的运行态，我的数据库可能也需要进行相应的数据库实例层面的拆分，比如说我的供应商和订单，我要拆到一个数据库实例里面，我的库存我要拆在一个数据库实例里面。但是这个东西最好对上层是透明的，所以说为了达到这个目的，我需要在数据库上面构建一个自动扩展的DaaS统一访问层代理，通过这个DaaS层来自动的统一出口，实现类似于对关联SQL查询的统一处理。

所以说在这种情况下面我们可以看得到，在开发态我仍然是按照单体架构组件化开发的方式去做开发，去做逻辑架构的设计。但是到了运行态，我会去自动增加rpc的进程间通信代理，自动扩展数据库访问的DaaS层。实现我在运行态能够根据我的性能将组件自动化的拆分，去做动态的去做部署和扩展，这个才是我们讲的微服务2.0最最核心的一个内容。

好了，今天呢简单分享就到这个地方，希望对大家有所启发。