工作10来年了,记性越来越差了,想想得留下点什么,以备查方便。回想起以前可以凭记忆,用记事本写代码的日子,现在却让人唏嘘不已……
这里我不想写太多官方标准,堂皇的话,把一些新同学或者记性不太好的,看的一愣一愣的,尽量用最朴实的语言,让人一看就明白,一看就回忆起来可以立马上手。
学习spring cloud 本教程前,得具备如下基础,否则请 return;
1、有Java基础,会使用eclipse或者 IDEA,Maven,Linux基础
2、有开发过 java web型项目,比如网站、商城啥的
3、会使用 spring boot
微服务是什么?
1 微服务怎么来的?
单体项目架构知道吧?就是你平常写的简单网站、商城啥的都属于单体架构,现在用户访问量太大了,速度慢;功能模块多,拓展维护开发麻烦。他就出现了,他就是解决这个问题的,他就是微服务。有人会说,他也可以是分布式或者集群啊,其实分布式也是属于微服务的一部分,只不过,他之所以叫分布式,不叫微服务,是因为分布式没有划分的那么清楚。
综上所述,你也可以这么理解, 传统单体架构 -> 分布式/集群 -> 微服务。
还有不明白的,请参考: https://blog.csdn.net/albenxie/article/details/77648014
2 什么是微服务 ?
微服务只是一种架构风格而已,他是把一个大型复杂项目拆分成多个单独的小项目,单独部署,单独维护,单独开发,这些不同的小项目,可以使用不同的语言和不同的数据库开发,降低了耦合性。(例如:一个大的商城项目,把用户模块,订单模板、仓库模块、商品模板等等,单独拆出来,作为不同的项目,进行开发维护)
那么拆分成这么多的单个项目,该如何管理呢,他们之间如何关联呢?该用户什么技术呢?这个时候就需要比较流行的 Spring Cloud和Dubbo了。下篇会讲到。
3 微服务优缺点
传统单体项目缺点:项目一旦过大,开发维护速度过慢,耦合依赖性太强,启动时间较长........
微服务优点: 只专于某一个业务功能开发,每一个业务就是一个项目,由不同的团队独立开发,互不影响,大大提高项目开发效率;每个项目单独部署和启动,在频繁发布某个单独项目时,其他项目不受影响,提高了可用性和稳定性。
微服务缺点:
分布式事物问题;(例如:单体项目架构商城,用户购买一件商品,仓库库量减少,都在一个项目中,只需要开启一个事物,如果出现失败,回滚就好了;但是在微服务架构中,商品模块和仓库模板,都是单独部署的项目,不在一个数据库中,如果出现问题,这时候就没法回滚)
需要管理多个服务问题,增大运营成本(因为部署了多个项目,如果某个项目挂了,就没法知道)
4、什么时候使用微服务
微服务的初衷是好的,但当整体实现时,也会出现各样的复杂性,需要再选择微服务时,一定要根据实际情况来定。
4.1 微服务很流行,用的公司也广,但是在使用时请认清他带来的挑战,技术人才各方面是否准备充足。
4.2 你的项目当前是否真的适合微服务,千万不要为了微服务而微服务,在前期资金困难和人员不足的情况下,请慎之。
4.3 流行的不一定是好的,适合自己公司当前使用的才是最重要的,可以在决定引入微服务之前,对原来的项目进行部分微服务改造,循序渐进,积累经验,以防不测!
4.4 最后,我想说的是,大家都创过业,创业都不容易,老板每一份钱都来之不易(哪怕是融资的),不要团队一组建,就大刀阔斧搞改革,要有个过程,新技术,新人才,工资成本都不低,要把钱留出来搞运营推销,项目技术再流弊,没钱推广了,也得死翘翘。。。。