微服务的拆分

我们都知道现阶段我们需要吧我们的项目拆分成微服务，
呢么重点关注
我们是什么时候做的拆分?
拆分的时候力度怎么把控，拆分的更细么  这是我们做微服务拆分要考虑的东西
首先微服务拆分的时机  需要进行微服务拆分的场景

我们看微服务拆分，什么时候进行的拆分
在单体项目中像我们的订单 并发都比较高，注册这些并发比较低，但是为了迎合订单系统的高并发，我整个项目都的扩容 都需要升级，浪费资源
拆分微服务之后我订单服务 我就可以进行横向扩容了，比如说我订单服务部署10个节点， 我注册服务部署2个节点  而且是相互不依赖
把我们主要业务和次要业务分开 分开之后进行扩容

什么时候需要进行微服务的拆分
公司要吧一个项目改成微服务架构的化
1.业务规模达到一定规模， 刚开始抢占市场的时候  越简单越好（单体比较好）比如说你的项目经历了市场的考验,开始融资了，流量起来了 并发上来了
这个时候就需要考虑拆分了,
2.团队规模（主要还是取决于业务复杂度）
3.技术以及人才的储备，因为服务一旦拆分成微服务， 注册中心了，日志系统了 监控系统了 分布式定时任务了 Cap  以及分布式调用链路这些都的考虑到

 你去做微服务拆分的时候有那些层面的考虑 
 前端-->nginx 反向代理------>gateway网关（高可用）-->后台高可用服务
  流量入口 在网关 做高可用
微服务拆分的策略  有2种 业务复杂度高 可以用DDD来进行拆分，业务复杂度低可以基于数据库来拆分
数据库的拆分就是比如说我的营销有几个表， 活动有几个表，商品有那些表
可以分成 营销中心， 活动中心 商品中心 这些 
/// 业务复杂度高的化 可以使用DDD来拆分

还有个拆分场景 就是从已有的单体架构 慢慢拆成小的项目（优先拆去公共服务，或者说不变的 比如说授权中心，日志中心 或者 分布式ID服务）
不断的从老系统抽取服务进行垂直拆分，适当进行水平扩容

涉及到微服务的拆分，我们就会定义技术选型，现版本一般会用springcloudAlibaba

我们通常会做服务的拆分以及数据库的拆分

我们拆微服务也会拆数据库 ，数据库以及微服务会部署在不同的节点上
假设我们现在拆分了 member(会员服务)，和商品服务 ，这2个服务都是一个独立的
Springboot项目， 我们接入springcloud第一步就是要引入nacos做服务注册和发现，
会员调用商品服务的化，我怎么知道你此时商品服务部署了几个节点
假设商品服务有10个节点的化，有8个可用的，2个挂了的 我会员服务怎么知道你是有2个挂了 8个可用
nacos可以帮助我们发现商品服务有几个节点，商品服务起来后可以在注册中心注册
这样会员服务在发起调用的时候就可以知道到底有几个商品服务的节点了
会员服务就可以从nacos拉取服务列表 缓存到本地，根据LB算法发起调用
引入nacos-discovery的依赖，配置nacos的注册中心地址

引入配置中心nacos-config,bootstrap 中添加相关的配置
我们可以吧redis 的相关配置配置在nacos的配置中心上

通过引入注册中心以及配置中心,我们就吧我们的服务交给了nacos进行管理
这个时候微服务还有个重要的特性就是服务之间发起的调用
在启动类上加了enableFeignClients支持
这个时候就可以引入openFeign来发起调用了，也可以开启feign日志
看看调用的具体情况

1.技术选型这个很重要 接入微服务的化，首先要考虑的是springcloud的那个版本
2.服务的拆分，数据库的拆分这些东西前期你都要做规划的
3.快速接入微服务 接入nacos注册中心，以及nacos配置中心 基于openfeign发起调用  开发前期一定会用到了
4.我现在基于我微服务的安全考虑 我微服务肯定是不能暴露出去的，需要引入网关 做统一的流量入口 权限的控制之类的  用springcloud-gateway 
作为网关他是路由 我的请求过来怎么调用到那个服务 取决于我路由的配置

我要用网关去统一我们的流量  让我们的请求统一进入走我们的网关,这个时候微服务多了怎么办
我们可以接入skywalking链路追踪  我们只需要在jvm参数中增加agent配置就可以了
  

不用导入jar,只需要在启动的时候配置agent,这样我发起个调用，在skywalking中就可以收集到我的数据
我的链路追踪数据 我在springcloud gateway中发起调用的时候，skywalking 就会采集到我们的链路信息

我们可以具体看看我们的链路信息,通过什么方式调用的，耗时是多少，最后调用到我们mysql 

如果有异常的化我们就可以知道 并且可以快速定位到问题，链路追踪可以帮我们快速定位问题，或者说在那个环节比较费时 我们也都可以发现，skywalking的好处就是没有侵入性
我们微服务在一直运行，会产生很多日志，我们可以做日志收集 比如说elk 结合traceId快速找到
上下游日志

整合elk filebeat做日志收集,有些不用过滤的 直接存储在es 有些需要过滤的 我们可以用logbash 进行过滤
最终将日志存储在es当中，然后借助kibana进行展示
收集到es之后我们就可以 在es中看到对应的日志了  这样也可以快速帮助我们排查问题
我们可以利用我们的elk进行收集日志 然后再用kabana去观察 利用es检索 快速定位到我们的异常 


CICD 持续集成和交付  测试就可以在jks一键部署
code--->gitlab--->部署（maven build 发到测试环境）   用maven去构建 构建完毕之后自动发布到服务器上

我们在进行cicd落地的时候  要去想那些git地址  源码分支从那些分支上拉代码

可以定时构建 比如说我早上6点定时构建
对于开发而言 只需要吧代码提交到git就可以了
gitlab会合并 然后jks上一点击， 就会从git上拉分支进行部署  
jks可以集成一些插件比如说sonar 做代码扫描
这样就可以体现开发团队对于项目把控  这些都可以在构建过程中做的