This commit is contained in:
by931
2022-09-06 22:30:37 +08:00
parent 66970f3e38
commit 3d6528675a
796 changed files with 3382 additions and 3382 deletions

View File

@@ -158,9 +158,9 @@ function hide_canvas() {
<p>首先,我以我自身的两份工作经历,来让你感受下什么是微服务,以及微服务架构的优缺点。这样有利于你理解后面的课时内容,同时更加有代入感。</p>
<h3>单体应用架构下的服务特性</h3>
<p>我第一份工作是网络游戏的测试保障工作,在功能测试之外做了很多服务端相关的工作,如编译后分发、配置、部署、发布等。那时候的服务端应用程序是几个独立的几十兆、上百兆的文件。<strong>每个文件是一个可执行文件,包含一个系统的所有功能,这些功能被打包成一体化的文件,几乎没有外部依赖,可以独立部署在装有 Linux 系统的硬件服务器上。</strong> 这种应用程序通常被称为单体应用单体应用的架构方法论就是单体应用架构Monolithic Architecture。单体应用架构下一个服务中包含了与用户交互的部分、业务逻辑处理层和数据访问层。如果存在数据库交互则与数据库直连如下图所示。</p>
<p><img src="assets/Ciqc1F8VMbWADRXPAABfysmIcFg665.png" alt="Drawing 0.png" /></p>
<p><img src="assets/Ciqc1F8VMbWADRXPAABfysmIcFg665.png" alt="png" /></p>
<p>单体应用架构下,一个服务中,两个业务模块作为该服务的一部分存在同一进程中,它们通过方法调用的方式进行通信,如下图所示。</p>
<p><img src="assets/Ciqc1F8VMb6AFe-pAAAxKvxK3wA298.png" alt="Drawing 2.png" /></p>
<p><img src="assets/Ciqc1F8VMb6AFe-pAAAxKvxK3wA298.png" alt="png" /></p>
<p>通过在单体应用架构下,不同阶段的服务端相关工作,可以感知到<strong>单体应用的特性。</strong></p>
<h4>1. 日常研发测试阶段</h4>
<ul>
@@ -178,10 +178,10 @@ function hide_canvas() {
<p>现在应用程序日益复杂化,项目对于迭代速度的要求也越来越高,上述的不足会暴露得更加明显,在这种时代背景下,微服务架构开始在企业生根发芽。</p>
<h3>微服务架构下的服务特性</h3>
<p>后来我转到了互联网公司工作,所在项目的服务架构与过去经历过的单体应用架构下的服务差异巨大。同等规模的研发团队,服务的个数竟然有近百个,虽然数量众多,但<strong>每个服务都只负责一小块儿具体的业务功能能独立地部署到环境中服务间边界相对清晰相互间通过轻量级的接口调用或消息队列进行通信为用户提供最终价值。这样的服务称为微服务Microservice</strong> 从本质上来说微服务是一种架构模式是面向服务型架构SOA的一种变体如下图所示。</p>
<p><img src="assets/Ciqc1F8VMgmAbQ0RAACD0qeLHMs761.png" alt="Drawing 4.png" /></p>
<p><img src="assets/Ciqc1F8VMgmAbQ0RAACD0qeLHMs761.png" alt="png" /></p>
<p>上图所示,微服务架构下,业务逻辑层被分拆成不同的微服务,其中不需要与数据库交互的服务将不再与数据库连接,需要与数据库交互的服务则直接与数据库连接。</p>
<p>微服务架构下,因为两个服务分别在自己的进程中,所以它们不能通过方法调用进行通信,而是通过远程调用的方式进行通信,如下图所示。</p>
<p><img src="assets/Ciqc1F8VMhGAIS2iAAAyeIWdJZ4810.png" alt="Drawing 6.png" /></p>
<p><img src="assets/Ciqc1F8VMhGAIS2iAAAyeIWdJZ4810.png" alt="png" /></p>
<p>同样,通过在微服务架构下,不同阶段的服务端相关工作,可以感知到微服务的特性。</p>
<h4>1. 日常研发测试阶段</h4>
<p>因为微服务数量众多,研发和测试团队都有诉求构建一个良好的基础建设。如搭建持续交付工具,通过持续交付工具拉取某微服务代码,再进行编译、分发、部署到测试环境的机器上。再加上,微服务应用程序本身并不大,部署耗时短、影响范围小、风险低,整个编译分发部署的过程在几分钟之内就可以搞定,且几乎是自动完成,因此部署频率可以做到很高。</p>
@@ -192,7 +192,7 @@ function hide_canvas() {
<h4>4. 其他阶段</h4>
<p>架构设计方面,微服务可以使用不同的语言,采用不同的架构,部署到不同的环境。同时可以采用适合微服务业务场景的技术,来构建合理的微服务模块。</p>
<p>由此可见,微服务的确解决了单体应用架构下服务的诸多短板。单体应用与微服务对比总结如下。</p>
<p><img src="assets/CgqCHl8VMjCAeWiUAAB11eN264M629.png" alt="Drawing 8.png" /></p>
<p><img src="assets/CgqCHl8VMjCAeWiUAAB11eN264M629.png" alt="png" /></p>
<h4>微服务的缺点</h4>
<p>当然,<strong>事物都有两面性,任何一项技术都不可能十全十美,在解决一定问题的同时,也会引入新的问题。</strong> 那么,微服务架构下服务有哪些缺点呢?</p>
<p>从微服务架构设计角度来看。</p>