|
你喜不喜欢微服务，现在微服务无疑已经是程序员们绕不过去的话题了。无论你是想把目前的架构改成微服务，还是你要出去面试高级一点的岗位，需要深入理解微服务。
提起微服务，很多程序员对它是又爱又恨，想学微服务不知道如何开始，学了一点之后，又找不到地方去实践。总之就是感觉微服务遥不可及，又很难驾驭。
首先要明白的是微服务是有套路的，而这些套路基本上解决了微服务结构面临的几乎所有重要问题。
这些套路就是微服务自己的架构模式
如果我们能深入了解这些模式的其来龙去脉，就可以理解了微服务绝大部分内容。学习快速，实用价值也极大。
1. 微服务最基本的模式
这篇文章先来讲第一个最基本的模式，这个模式我估计需要三篇文章才能讲透，这是上篇。打算中篇写实践，下篇写问题。
希望大家能学的轻松。
微服务最基本的模式就是：图就是一个最简单的微服务模式了。
一个服务一个数据库这种模式，是微服务体系结构中的最基础也是最核心的模式。看着简单，但是，这个模式蕴含着微服务的最基本的思想。
要弄清楚一个服务一个数据库这种模式，首先我们就需要问一下，为什么我们要搞微服务。
2. 传统系统的问题
在谈及微服务的时候，和微服务对应的概念叫做单体系统( Monolithic application )。简单说，微服务是为了解决单体系统的问题才衍生出来的。单体系统结构如下图:么这种单体结构出现了什么问题，导致现在大家必须开口闭口微服务了呢?
3. 单体系统太大了
最首要的一个原因就是应用系统太大。而由于应用系统的过于庞大，如果仅是单体系统的话，就引发了各种各样的问题，体现在以下三个方面：
3.1. 系统本身业务复杂，模块众多
系统随着时间的发展，业务需求越来越多。而为了满足这些需求，就导致整个系统的模块越来越多。而系统模块越来越多，就导致能理解整套系统的人变得越来越少，直到最后没有人可以理解整套系统。
3.2. 系统的代码库非常庞大
代码量也会随着系统的增大而增大，代码量的庞大影响了整个开发流程，会导致整个开发成本变得很高。
-
首先，代码量大，依赖关系复杂，所以对新接手的开发人员来说，配置开发环境非常耗费精力。
-
其次，代码量大，加载这些代码和对应的依赖需要的内存就多，所以就会导致开发人员的 IDE 运行非常缓慢，导致编辑代码都很麻烦。
-
再次，代码量大，如果要把整个代码编译打包，需要的内存也很多，所以也会导致功能开发完成后，对系统的构建会非常缓慢，导致整个构建的时间非常漫长。
-
再有，代码量大，几乎没人能对整体代码有比较深入的了解，哪怕可能其中一个要改动的功能，都会因为过于复杂导致开发人员理解不深入。而这些不深入的理解又会让开发人员不能使用最佳的方式去做功能开发，从而导致隐藏的 bug。
3.3. 技术团队变得非常庞大
由于功能模块越来越多，这就需要越来越多的开发人员去开发和维护这套系统。但是，这些开发人员都是面对的同一套代码库，虽然可以搞分支，大家各搞各的。可是一旦需要合代码，发布上线，就是场噩梦。
各种代码冲突，代码丢失，都可能在上线的时候发生。
不仅如此，由于顾虑代码丢失和冲突，就需要在上线前，进行足量的测试，而这些测试又需要投入巨大的时间成本。
但是，现在都讲敏捷开发，很可能在还没上线的时候，后续的业务需求又接踵而至，简直要命。
（编辑：文章分享网_茂名站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
