MSB-001-架构之路

一、架构师基本技能

 

1.比产品更懂产品

2.部门协调能力

3.沟通能力

4.技术能力

木桶效应：取决于最短的那一块儿

思想：业务决定技术，技术是为业务服务的，相辅相成。

知道公司的前进方向和战略部署，然后围绕这两个答案带领团队，设计产品

1.熟悉团队

2.达成共识，人力、时间、技术成本

3.介绍业务

4.设计架构

二、ECS配置：

CRUD标准最低配：双核CPU2 内存4G   硬盘40G  5M带宽(按照传输业务分配) 64位处理器为标配

 

 

三、架构问题

1、ABC三个服务，如果A-->B-->C链路反应缓慢，有时还会超时，那么应该如何处理？

增加SkyWalking链路追踪，定位哪个服务耗时较长。

定位之后如何处理：

使用超时机制，设置服务超时时间，这样如果A很慢，那么A超时后会释放资源，不会影响B和C。

服务之间不会相互影响，且不会让用户长时间无响应，此时使用的超时机制，我们称之为降级。

如A-->C，A占用了C的资源，如果A超时后，回调callback方法，释放掉C的资源，这称之为降级。

当A一直有问题，一直出现降级的时候，那么可以对A进行熔断，不再调用C服务，这称之为熔断。

2.架构所需集群

增加熔断服务配置集群，用来保存熔断规则，归属于配置中心。

增加监控服务器集群，当服务发现Erroe时，需要发邮件告警。

日志服务集群，普通研发无法登录生产服务器查看日志，所以需要日志服务集群收集日志，进行存储。

GateWay集群：接入层服务器可以用来验证、授权、路由、转发、调用服务、熔断、降级等功能，我们称之为Gateway集群

3.Dubbo和SpingCloud的区别

答：Dubbo是alibaba开发的，alibaba是一家商业公司，如果在外面没有竞争的情况下，商业公司是不会做不利己的动作的，不会做的更好，会站在原地不动，没有必要创新，不会带来更多的价值，dubbo停更了一年。而SpingCloud后来居上，dubbo便开始继续更新，但是玩不起来了，因为dubbo刚开始设计时就是一个RPC框架，SpringCloud的理念是生态，是一整套微服务的解决方案。所以就阿里不得不搞出了SpingCloud-alibaba来搞SpingCloud-NetFlix那一套，SpingCloud-NetFlix主要包含Eureka、zuul、Ribbon、feign、Hystrix、turbine。

SpingCloud解决了什么问题呢？

答：JavaSe和J2EE的意义在哪里？SpingCloud规定了你想接入SpringCloud的生态，定义了标准接口，比如熔断接口、服务查找接口，然后让第三方来接，何乐而不为。

四、项目持续集成

Jenkins服务器SSH给业务服务器1、业务服务器2，让他们将gitlab上的代码拉取下来进行mvn编译打包。用jenkins首要任务就是在业务服务器端生成一个RSA的对称秘钥，然后把秘钥配置在jenkins服务器端，只要有了这个秘钥，才可以通过ssh命令调用业务服务器。jenkins将打包生成的镜像推送给harbor镜像仓库，然后K8S的mater拉取镜像执行。

 

 五、三高项目业务详解

1.分清楚动态数据和静态数据，动静分离

静态数据可以放Nginx或CDN，直接走缓存，性能较快。

2.订单业务

1）下单如何提高并发？

因为大量的并发都要抢一个资源，那么肯定会遇见性能的问题。访问量大是瓶颈

下单的时候库存要加锁，不能超卖不能少卖，得有隔离性和互斥性，要保证数据的一致性。

处理高并发总体思路：

1.负载均衡

2.缓存，减少链路的深度

3.消息队列，肖锋，解耦

4.分库分表

5.请求合并，多个静态文件请求合并为一个请求，减少页面依赖(如去除广告等无关功能)达到高可用，总的来说就是减少传输。

6.请求路径为短路径，即短url，可以做缓存。

7.避免单点

8.限流、拒绝，动态扩缩容

9.详情页使用CDN

库存的思路：

锁库存，如何处理这个瓶颈？

负载均衡，分库分表

redis处理，商品id-库存-1:10，商品id-库存-2:10

支付-》减库存，放入消息队列处理。