pigx微服务 项目 打包 微服务war包

微服务 & 微服务架构

单体架构 VS 微服务架构

单体架构

一个工程对应一个归档包(war)，这个war包 包含了该工程的所有功 能。我们成为这种应用为单体应用，也就是我们常说的单体架构(一个 war包打天下)。 具体描述: 就是在我们的一个war包种，聚集了各种功能以及资源，比 如JSP JS,CSS等。而业务种包含了我们的用户模块，订单模块，支付模块等 。

单体架构图

单体架构优缺点总结

优点：

1.架构简单明了，没有”花里胡哨“的问题需要解决。
2. 开发，测试，部署简单（尤其是运维人员 睡着都会笑醒）。

缺点：

1. 随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的 水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。
2. 部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部 署的速度 (15分钟)。
3. 扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模 块(涉及到大量的运算)那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更 加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU 更牛逼的内存 更牛 逼的磁盘 价格蹭蹭的往上涨。
4. 阻碍了新技术的发展。。。。。。比如我们的web架构模块 从 struts2迁移到springboot，那么就会成为灾难性

微服务以及微服务架构

微服务定义

“微服务”与“微服务架构”有着本质的区别：“微服务”强调的是服务的大小，它关注的是某一个点。而“微服务架构”则是一种架构思想，需要从整体上对软件系统进行通盘的考虑。

微服务核心

就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务.①: 比如传统的单机电商应用, tulingshop 里面有 订单/支付/库存/物流/积分等模块(理解为servcie)②:我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服务，积分服务 ③若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个服务宕机. ,若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用

单机架构扩展与微服务扩展图解

单机架构

微服务架构以及扩展

微服务数据存储

什么是微服务机构

微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服务。
微服务架构是一个架构风格, 提倡
①：将一个单一应用程序开发为一组小型服务。
②：每个服务运行在自己的进程中。
③：服务之间通过轻量级的通信机制(http rest api)。
④：每个服务都能够独立的部署。
⑤：每个服务甚至可以拥有自己的数据库。

优点：

①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码 需要了解整个系统)。
②：开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了。
③：微服务能够被2-5个人的小团队开发，提高效率。
④：按需伸缩。
⑤：前后段分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。
⑥：一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库。

缺点：

①：增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis )。

②：服务之间相互调用，增加通信成本。

③：数据一致性问题(分布式事物问题)。

④：系能监控等,问题定位等。

微服务的适用场景

合适：

①：大型复杂的项目…(来自单体架构200W行代码的恐惧)。
②：快速迭代的项目…(来自一天一版的恐惧)。
③：并发高的项目…(考虑弹性伸缩扩容的恐惧)。

不合适：

①：业务稳定，就是修修bug ，改改数据 。
②：迭代周期长 发版频率 一二个月一次。

Spring Cloud Alibaba

什么是什么是SpringCloud？

SpringCloud是程序员用来开发我们微服务的一整套技术解决方案.包含如下服务注册发现，服务容错降级，服务网关，服务调用，服务调用负载均衡,消息等。

功能描述

什么是Spring cloud Alibaba?

Spring cloud Alibaba是我们SpringCloud的一个子项目,是提供微服务开发的一站式解决方案.包含微服务开发的必要组件。

文档

https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

功能描述

SpringCloud SpringCloudalibaba SpringBoot的生产版本选择

我们的SpringBoot版本 说明选择

1、其中2：表示的主版本号，表示是我们的SpringBoot第二代产品

2、其中1:表示的是次版本号，增加了一些新的功能但是主体的架构是没有变化的，是兼容的

3、其中6:表示的是bug修复版

4、所以2.1.6合起来就是springboot的第二代版本的第一个小版本的 第6次bug修复版本

5、RELEASE:存在哪些取值了 ①:snapshot(开发版本) ②:M1…M2(里程碑版本,在正式版发布之前 会出几个里程碑的版本) ③:release(正式版本)

Spring cloud的版本说明

第一代版本:Angle。
第二代版本:Brixton。
第三代版本:Camden。
第四代版本:Edgware。
第五代版本:Finchley。
第六代版本:GreenWich。
第七代版本:Hoxton(还在酝酿中，没正式版本)。这种发布的版本是 以伦敦地铁站发行地铁的站。

为什么我们的SpringCloud会以这种方式来发布版本

因为假如我们传统的5.1.5release这种发布的而 SpringCloud会包含很多子项目的版本就 会给人造成混淆

**SNAPSHOT： 快照版本，随时可能修改。

**

M： MileStone，M1表示第1个里程碑版本，一般同时标注PRE，表示预览版 版。

**RC 版本英文版名字叫Release Candidate（候选版本）一般标注PRE表示预览版。

**

**SR： Service Release，SR1表示第1个正式版本，一般同时标注。

**

GA：(GenerallyAvailable),表示稳定版本。

比如还有一种RELEASE版本（正式版本） 比如 Greenwich版本顺序Greenwich.release----->发现bug----->Greenwich.SR1------>发 现bug----> Greenwich.SR2。

SpringCloud的发布计划

https://github.com/spring-cloud/spring-cloud- release/milestones

SpringCloud曾经发布的版本:

https://github.com/spring-cloud/spring-cloud-release/releases

Springboot SpringCloud SpringCloudalibaba 的版本对应关系

https://github.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E

生产版本选择

a:打死不用 非稳定版本/ end-of-life（不维护）版本。
b:release版本先等等(等别人去探雷)。
c:推荐 SR2以后的可以放心使用。

微服务注册中心Nacos入门

https://nacos.io/zh-cn/docs/what-is-nacos.html

服务的提供者 &服务的消费者是相对的概念比如用户服务是订单服务的消费者，订单服务是用户服务的提供者。但是对于 订单服务---->库存服务，那么订单服务就成为服务消费者.

无注册中心的调用的缺点。

比如现在我的用户服务是占用(User服务)8081端口的服务, 此时我的服务提供方(order服务端口是8080)端口;

我们可以通过RestTemplate 调用方式来进行调用

缺点：

1)从上面看出的缺点就是，我们的在调用的时候，请求的Ip地址和端口是硬编码的若此时，服务提供方(order)服务部署的机器换了端口或者是更换了部署机器的Ip,那么我们需要修改代码重新发布部署。

2) 假设我们的order服务压力过大，我们需要把order服务作为集群，那么意味着 order是多节点部署 比如原来的，我们只有一台服务器，现在有多台服务器，那么作为运维人员 需要在服务消费方进行手工维护一份注册表(容易出错)。

3)有人马上回驳我说，我可以通过ng来做负载均衡,对，我首先认为这是可行的，当时微服务成百上千的服务，难道我们要那成百上千ng么？或者使用一个Ng 那么我们能想一下哪个ng的配置文件有多么复杂。

服务注册发现原理V1架构图：

V1版本的架构，存在以下几个问题

①:我们的微服务每次调用，都会去进行对数据库的查询，并发一高，数据库性能就是一个瓶颈问题。
②:若我们的mysql挂了，那么我们所有的微服务调用都不能正常进行。
③:若mysql是正常的,库存微服务挂了，那么也不能正常的调用。

V2版本架构图

Nacos服务端搭建

下载地址:https://github.com/alibaba/Nacos/releases。

linux环境启停:

①:把我们的Nacos包解压 tar -zxvf nacos-server-1.1.4.tar.gz

②：cd 到我们的解压目录nacos cd nacos

③：进入到bin目录下 执行命令(启动单机) sh startup.sh -m standalone

④:检查nacos启动的端口 lsof -i:8848

⑤:访问nocas的服务端 http://192.168.159.8:8848/nacos/index.html 默认的用户名密码是 nocas/nocas

⑥：停止nocas 在nocas/bin目录下 执行 sh shutdown.sh

window环境下 启动nocas server

4：Nacos client服务端的搭建

①:三板斧之:第一板斧 加入依赖

②:三板斧之:第二板斧写注解(也可以不写) @EnableDiscoveryClient

③:第三板斧之:写配置文件

注意

server-addr：不需要写协议

④:验证我们的order-center注册到我们的nacos上

5：Nacos 领域模型划分以及概念详解

5.1)NameSpace(默认的NameSpace是”public“ NameSpace可以进行资源隔离，比如我们dev环境下的NameSpace下的服务是调用不到prod的NameSpace下的微服务)

证明1)我们dev环境下的order-center 调用 prod环境下的product-center ①:order-center所在的namespace为dev

②:product-center所在的namespace 为prod。

③：测试调用: http://localhost:8080/selectOrderInfoById/1

5.2) Nacos的集群模式

5.2.1)首先 我们需要安装我们的ng

第一步:下载ng （老师下载的是:路径是/usr/local/software）

第二步:解压ngtar -xzvf nginx-1.14.2.tar.gz 得到解压目录

第三步: 进入解压目录 cd nginx­1.14.2

第四步: 执行命令指定安装目录

./configure ­­prefix=/usr/local/nginx­1.14.2 意思是告诉等会安装的文件要放在哪里

第五步: 接下来通过命令 make 编译执行 make命令

第六步:执行 make install 命令

第七步:还记得第四步我们安装ng的目录么？ /usr/local/nginx­1.14.2 进入该目录下的配置目录conf

第八步:修改ng的conf文件

5.2.2)安装 我们的nacos­server(搭建三个集群端口分别为8849 ,8850,8851)

我们以配置一台为例（8849）为例第一步:修改nacos8849/conf文件 application.properties

第二步:修改nacos8859/conf文件 把原来的cluster.conf.example改为cluster.conf文件

文件内容为如下

到此为止 nacos8849安装完成了 nacos8850 nacos8851同样安装.

5.2.3)最后一步：创建一个数据库（需要自己创建一个数据库） 脚本的位子在 nacos/conf/nacos-mysql.sql

5.2.4)需要修改nacos-server的 启动脚本jvm参数 (怕你们内存参数设置的过小启动不了这么多服务)

5.2.4)分别启动 8849 8850 8851 进入到 nacos的目录下的bin目录

执行./start.sh启动成功的依据

查看日志/usr/local/spring-cloud-alibaba/nacos/nacos8850/logs/start.out

测试:分别登陆地址:

http://192.168.159.8:8849/nacos http://192.168.159.8:8850/nacos http://192.168.159.8:8851/nacos NG测试http://192.168.159.8:8847/nacos/

客户端地址: 直接填写8847ng的地址就可以了

什么是配置管理??

上图缺点:

所有的环境的配置都是明文的 被太多开发人员都知道了。 业务场景：张三开发了一个新功能,业务需要，保留原来老逻辑的代码，所有他抽取了一个 开关变量 isNewBusi来控制，突然新功能上了生产后，发现有bug,怎么做到修改isNewBusi的值不 需要重启。

根据上图我们知道配置管理的作用可以主要总结如下

1）不同环境不管配置

2) 配置属性动态刷新

引入配置中心

根据这幅图，我们微服务需要解决的问题

1)我微服务怎么知道配置中心的地址。

2) 我微服务到底需要连接哪个环境。

3)怎么找到nacos config上的对应的配置文件。

微服务接入配置中心的步骤

①:添加依赖包spring-cloud-alibaba-nacos-config

②:编写配置文件,需要写一个bootstrap.yml配置文件 配置解释:

现在我们需要不停机改变我们的生产环境isNewBusi的值来控制我们的业务逻辑。我们需要在对应的Controller上添加一@RefreshScope 进行动态刷新

6.2）怎么解决 生产环境，测试环境，开发环境相同的配置。（配置通用）

比如我们的servlet-context 为order-center 查看工程启动日志

所以我们需要创建一个通用配置文件:order-center.yml配置 那么order-center.yml就是一个通用配置了，不管是启动prod,还是dev 都会有该段配置order-server的 context-path 配置

配置的优先级 精准配置 会覆盖 与通用配置 相同的配置，然后再和通用配置互补。

6.3)不同微服务的通用配置。

6.3.1)通过 shared-dataids 方式比如 每一个微服务都要写服务注册地址等

我们就可以把该配置提取为一个公共配置yml,提供给所有的工程使用

6.3.1)通过 ext-config方式同样配置到越后面的配置 优先级越高

6.3.3)各个配置的优先级 精准配置>不同环境的通用配置>不同工程的(ext-config)>不同工程(shared- dataids)