V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
longmeier90
V2EX  ›  Go 编程语言

问一下大家要想成为架构师需要掌握什么技能?

  •  
  •   longmeier90 · 2022-09-21 17:59:11 +08:00 · 2177 次点击
    这是一个创建于 792 天前的主题,其中的信息可能已经有所发展或是发生改变。

    这几天 app 老是转圈( tornado 开发)领导天天问我咱们架构行不行,要不要换语言重构。 我认为的后端架构不就是懂这些吗: k8s+docker+nginx+supervisor+gunicorn+ansible 部署项目 python 、go 开发项目 redis 、rabbitmq 队列 mysql 、pg 、elk 、cassandra 数据库 etcd 配置中心

    还有什么是我需要掌握的? (其实我觉的我欠缺的是系统的业务架构:比如 分库分表、分布式事务、内存、cpu 的调优上。) .....

    其实我们的并发不太大,但是就是数据量大了,以前写的慢查询比较多。

    nginx 错误日志:recv() failed (104: Connection reset by peer)
    
    nginx 配置如下:
    upstream doctor_up {
       server 127.0.0.1:8400;
       server 127.0.0.1:8401;
       server 127.0.0.1:8402;
       server 127.0.0.1:8403;
       server 127.0.0.1:8404;
    
    }
    
    

    找了两天发现,nginx 打印错误都是在同一个端口上。而且顺着错误往上找在之前都会出现好几个请求访问时间 30s 左右。怀疑是不是写入数据的时候锁表,导致查询卡住,然后后台服务端口堵塞。nginx RST 连接 close 。 ============= [ pad ] 转圈问题处理方案===========

    1. [后端] nginx 连接数调高、buffer 缓存调大、keepalive 加了长连接
    2. [后端] 增加后台服务进程数
    3. [后端] 慢接口进行读写分离优化(分析错误日志,找到转圈时刻慢接口)
    4. [后端] 增加自动访问接口提醒功能(每分钟)
    5. [后端] 增加了调第三方服务超时时间
    6. [前端] 优化了超时时间 30 秒改 10 秒
    7. [前端] 优化了页面快速切换的重复请求
    7 条回复    2022-10-01 00:07:02 +08:00
    xuanbg
        1
    xuanbg  
       2022-09-21 18:16:42 +08:00
    性能问题要先看是前端的问题还是后端的问题。后端的话,接口响应时间能不能都控制在 100ms 以内?压测做一下看看服务器性能能不能挺得住用户量。。。一般性能问题和架构关系不大。
    jones2000
        2
    jones2000  
       2022-09-21 18:52:23 +08:00
    后台每个 api 都需要有详细日志记录,这样哪个时间段有问题好查。 监控系统对接日志服务,每周把慢的接口统计出来, 让后台改。 用户少,根本不需要什么构架, 一个 java 进程就搞定了, 哪需要部署这么多东西,东西越多出错的概率越大,人力成本也越大。
    shuimugan
        3
    shuimugan  
       2022-09-22 00:07:00 +08:00
    软考历年架构师真题看一下,有一说一里面很多题都挺潮的。
    oatw
        4
    oatw  
       2022-09-22 14:10:11 +08:00
    架构师关注更多的是边界和分离点,降低团队间、不同技术体系间的耦合度,做适合的选择和设计。在某个领域的深度不一定比工程师高,但通的要比较多,慎重引入技术体系,不做不必要的架构复杂度增长。

    现实情况是很多公司的架构师都被当成疑难杂症老中医使,只要是没人能搞或者没人愿搞的问题都扔给他。
    bwangel
        5
    bwangel  
       2022-09-25 17:38:31 +08:00   ❤️ 1
    看起来你应该需要加个监控

    如果是单服务,按接口加上请求时间,排队时间和 qps 的监控

    如果是多服务,http/grpc/thrift 的每个接口也都要加上监控。

    有了监控以后,看看哪些接口 qps 高 && 请求时间慢,针对接口优化就好。

    接口优化也简单,

    1. 看看 API 有没有返回多余的字段,能删就删
    2. 看看数据库查询是不是没命中索引,改查询条件或加索引
    3. 加缓存
    4. 看看一个 http 请求内是否重复了多个 rpc 请求,试着合并一下
    5. 如果一个请求的逻辑实在是复杂,看看能不能改交互,把逻辑改成异步的,实际功能在 mq 里面做。
    bwangel
        6
    bwangel  
       2022-09-25 17:41:39 +08:00
    这是性能角度的考虑,还有资源方面的考虑,服务占用的 CPU/内存

    建议直接上 k8s ,然后利用 k8s 提供的监控指标,查看每个 deploy/job 占用的资源。
    guanhui07
        7
    guanhui07  
       2022-10-01 00:07:02 +08:00
    好像 架构师 确实都是疑难杂症解决工

    架构师是 面 比较全 ,每个人都有擅长的
    分库分表 指的是 用 sharding 这种分区吗 还是 横 着切 ,我一般按区间
    分布式事务 TCC 现在 那个 DTM 用的多吗
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   960 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 21:38 · PVG 05:38 · LAX 13:38 · JFK 16:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.