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

[longmeier90]

这几天 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. [前端] 优化了页面快速切换的重复请求

[xuanbg]

性能问题要先看是前端的问题还是后端的问题。后端的话，接口响应时间能不能都控制在 100ms 以内？压测做一下看看服务器性能能不能挺得住用户量。。。一般性能问题和架构关系不大。

[jones2000]

后台每个 api 都需要有详细日志记录，这样哪个时间段有问题好查。 监控系统对接日志服务，每周把慢的接口统计出来， 让后台改。 用户少，根本不需要什么构架， 一个 java 进程就搞定了， 哪需要部署这么多东西，东西越多出错的概率越大，人力成本也越大。

[shuimugan]

软考历年架构师真题看一下，有一说一里面很多题都挺潮的。

[oatw]

架构师关注更多的是边界和分离点，降低团队间、不同技术体系间的耦合度，做适合的选择和设计。在某个领域的深度不一定比工程师高，但通的要比较多，慎重引入技术体系，不做不必要的架构复杂度增长。

现实情况是很多公司的架构师都被当成疑难杂症老中医使，只要是没人能搞或者没人愿搞的问题都扔给他。

[bwangel]

看起来你应该需要加个监控

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

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

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

接口优化也简单，

1. 看看 API 有没有返回多余的字段，能删就删
2. 看看数据库查询是不是没命中索引，改查询条件或加索引
3. 加缓存
4. 看看一个 http 请求内是否重复了多个 rpc 请求，试着合并一下
5. 如果一个请求的逻辑实在是复杂，看看能不能改交互，把逻辑改成异步的，实际功能在 mq 里面做。

[bwangel]

这是性能角度的考虑，还有资源方面的考虑，服务占用的 CPU/内存

建议直接上 k8s ，然后利用 k8s 提供的监控指标，查看每个 deploy/job 占用的资源。

[guanhui07]

好像 架构师 确实都是疑难杂症解决工

架构师是 面 比较全 ，每个人都有擅长的
分库分表 指的是 用 sharding 这种分区吗 还是 横 着切 ，我一般按区间
分布式事务 TCC 现在 那个 DTM 用的多吗