认识达内从这里开始

微服务架构随着互联网的不断发展而被众多程序员学习和应用，下面我们就通过案例分析来了解一下，微服务架构与单体架构的区别。

性能差异

与旧单体相比，LOSA架构的性能还不够好，通常需要400到600毫秒才能渲染出页面的特定部分。我们采用了异步Worker结构，这样就可以同时请求多项服务来渲染应用程序的不同部分(而不是渲染单个应用)。但这种作法提高了应用下线的难度，因为“生产故障”会导致侧边栏或页脚部分长时间缺失。因此，进一步拆分才是好的选择。

我所说的LOSA异步Worker是这样的：我们使用大量的Node服务，每一个服务负责渲染页面的一个或多个组件。

遗留控制器(图中的灰色齿轮部分)可以将视图数据转给POST请求，而非后端模板引擎。回收数据机制则能够帮助后端减少支持负担。由于无需做出重大修改，后端开发人员能够腾出时间，专注于解耦数据服务，而前端也可以进行独立的开发。

视图数据被发送给了外部的React服务，而响应消息(包含了HTML、样式表、初始状态以及CSSURL)则被发送给后端模板引擎。现在，模板引擎只需要渲染POST请求所对应的响应，从而将视图或视图的一部分与原有单体剥离开来。

React渲染时间

React真的很慢!SSR也不怎么快——因此新的LOSA架构解决方案无法带来理想的性能表现。我们的解决方案是：在React内部进行片段缓存。

黄色：无React片段缓存——端到端(400毫秒左右)

深紫：有React片段缓存——端到端(150毫秒左右)

橙色：全优化架构(20毫秒左右)

绿色(底部)：来自后端的原生片段缓存

React优化工作相当复杂，受篇幅所限，恐怕只能另起一篇文章详加说明了。总之，Graphana数据显示，我们至少将渲染性能提高了一倍，不过轮循时间仍然很长。尽管React已经能够在内部快速完成渲染，但150毫秒的端到端时间还没有达到我们的预期。在下一篇文章中，我们将具体聊聊片段后端与片段缓存。

渲染时间VS轮回时间

渲染时间一直是个麻烦事，即使是在React中采用了片段缓存之后，性能仍然无法令人满意。令我感到失望的是，虽然Node.js内部的渲染速度很快(约20毫秒)，但整个流程仍然需要140到200毫秒才能完成。

瓶颈所在

JSON大小，特别是初始应用状态——即渲染页面所需要的少state。我们不再在初始渲染中放置太多字符串化的state，只发送足够让React完成渲染并让折叠组件变得可交互的必要state。

需要渲染的DOM节点数量——不再将代码放在无用的DIV中，只需要给它们加个class。利用HTML的语义特性以及CSS的级联效果，我们可以少写一些HTML代码，这样也就减少了React.createComponent函数的生成。

垃圾回收——我们将在下一篇文章中讨论更多细节。

速度由数据服务决定——在中间层使用Redis。很多朋友认为“缓存失效问题难以解决”，我建议各位认真考虑一下事件溯源，或者我们可以使用CQRS与异步Worker来处理读写操作。

单体架构与MFE之间的HTTP开销——也就是gRPC、CQRS、UDP以及Protobuf。二者之间的通信应该通过内部Kubernetes网络进行。POST速度很慢，但也不是不能用。遇到问题时个别处理即可。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。