2、技术选型：创业初期，技术如何选型

no2：创业初期架构特点、选型依据、选型建议是什么？
- 特点：
  - 1.单机系统(All in one)
  - 2.程序耦合(All in one)
  - 3.逻辑核心是 CURD
- 主要依据：选择技术合伙人会的，熟悉的，是早期技术选型的
- 选型建议：
  - PHP体系：Linux、Apache、MySQL、PHP
  - Java 体系：Linux、Tomcat、MySQL、Java
no2：创业初期工程师的主要矛盾是什么？如何解决？
- 矛盾：业务开发效率与质量低，CURD 频繁出错
- 解决：尽早引入 DAO/ORM 技术
- DAO(Data Access Object)：像对象一样访问数据
- ORM(Object Relation Mapping)：简化数据库查询过程

3、技术选型：框架组件要不要自研，什么时候自研？

no3：框架组件要不要自研，什么时候自研？有哪 4 个观点？
- 1.早期不要自研，后期适当自定义
- 2.随着规模的扩大，要控制技术栈
- 3.建议浅浅的封装一层
- 4.随着业务规模，研发团队进一步扩大，适当造一些轮子
no3：为什么说早期不建议自研？
- 1.早期的业务以快速迭代为最高优先级，快速实现功能，让公司活下来最重要
- 2.技术栈选择技术合伙人最熟悉的
  - 研发语言：熟PHP选PHP，熟Java选Java
  - 数据库：熟MySQL选MySQL，熟SQL-server选SQL-server
  - 框架组件：熟Ruby on Rails选ROR，熟ThinkPHP选ThinkPHP，熟SSH选SSH
- 3.此时技术栈的选择对合伙人的技术视野有要求，能在未来少踩坑
no3：为什么要控制技术栈？
- 1.绝对不能每个人想用什么就用什么，否则会造成混乱
- 2.即使用开源，技术栈也尽量统一
no3：什么叫「浅浅封装一层」？好处是什么？
```
String Memcache::get(String key)
String Memcache::set(String key, String value)
String Memcache::del(String key)String 58DaojiaKV::get(String key) {String result = Memcache::get(key);return result;
}
```
- 好处
  - 对调用方屏蔽底层实现细节
  - 当底层变化的时候，调用方改动很小
  - 能很方便实现统一的功能，如时间统计等
no3：为什么说随着业务规模和研发团队的扩大可以适当造一些轮子？而不能全部使用开源？
- 不同技术团队，痛点是相似的
- 开源解决不了全部个性化需求
  - 有站点，监控服务的可用性，处理时间监控需求
  - 有告警需求
  - 有自动化发布，自动化运维需求
  - 有服务治理，服务自动发现需求
  - 有调用链跟踪需求
  - 有SQL监控需求
  - 有系统层面数据收集与可视化展现的需求
- 自研解决痛点，更贴合团队实际情况
  - 开源框架/组件太重了，我们需要的可能只是一个轻量级的框架/组件
  - 开源框架/组件，只能满足我们的一部分需求
  - 不了解开源框架/组件的设计理念，要二次开发成本更高
  - 有些通用的需求是和业务紧密结合的，开源框架/组件可能满足不了

4、容量设计：流量高低，对架构究竟有什么影响？

no4：什么时候要进行容量评估？
- 1.容量有质变性增长
- 2.临时运营活动
- 3.新系统上线
no4：哪些指标要进行容量预估？
- 看具体业务，对应到系统侧的主要矛盾是什么，如：
- 1.数据量
- 2.并发量，吞吐量
- 3.带宽
- 4.CPU/MEM/DISK 等
no4：如何进行容量评估(以吞吐量为例)
- 1.评估总访问量：询问产品、运营
- 2.评估平均访问量：总量除以总时间，一天可算 4w 秒
- 3.评估高峰 QPS：可根据业务曲线图来
- 4.评估系统、单机极限 QPS：使用压测
- 5.根据线上冗余度做决策：计算需求和线上冗余度差值

5、伪分布式：你以为，多机就是分布式？

no5：随着流量的提升，早期系统最先遇到的两大问题是什么？如何分析系统特点与瓶颈？
- 现象：人多的时候会卡(即慢，性能下降)，压力会导致宕机(即一挂全挂，耦合严重)
- 瓶颈分析：网络带宽、内存、CPU 计算、磁盘 IO
- 初步结论：ALL in one 导致单机资源称为瓶颈
no5：架构早期最快速地解决「单机资源瓶颈」问题的思路？做法？原因？
- 思路：
  - 增加硬件资源(时间短)，避免大规模代码重构(时间长)
- 做法：
  - 把「单机」变「多机」，用最小的成本，扩展资源
- 原因：
  - 此时最大的成本，是时间成本
  - 能用“钱”解决的系统问题，往往不是问题
  - 老板最不愿见到的，是解决一个系统问题，花很长的时间(市场和投资人等不起)
no5：「单机」变「多机」的伪分布式的「三大分离」应该怎么做？设计思路？没解决的问题？
- 三大分离
  - 1.读写分离(引发读写延时新问题)：将数据库的读写请求分散到不同的数据库机器上
  - 2.动静分离：将静态文件(css、jpg、静态页面)和动态生成的站点分离
  - 3.前台后台分离：前台即用户访问的系统，后台即运营使用的系统
- 设计思路：用最快的速度，增加硬件资源，提升系统性能，增加访问速度
- 没解决的问题：
  - 1.耦合问题：一个子系统挂了，仍然是全站挂
  - 2.主从延时新问题：读写分离只能提升读写性能，无法降低单库数据量
no5：如何解决「三大分离」的耦合问题和读写延时问题？设计思路？如何操作？
- 方案：业务垂直拆分，解耦
- 操作：
  - 1.业务垂直拆分
  - 2.代码垂直拆分(子系统耦合)
  - 3.数据库垂直拆分(数据量降低，延时缓解)
  - 4.研发团队垂直拆分(专业化，效率提升)
- 设计思路：用最快的速度，增加硬件资源，解耦
- 垂直拆分，会随着业务越来越复杂，不断持续地进行
- 存在问题
  - 1.对同一个垂直站点子系统，仍然是一个「单体架构」，每一个业务都并不是高可用的，子系统的性能仍然受到单机资源的限制无法扩展
  - 2.子系统不是高可用的，只能保证一个挂了，另一个不受影响

《沈剑架构师训练营》第1章 - 技术选型相关推荐

《沈剑架构师训练营》第3章 - 快速性能优化
11.性能优化:动静分离,互联网优化利器? no11:与静态页面.动态页面匹配的加速技术有哪些? 静态页面 CDN nginx squid/varnish 动态页面分层架构服务化架构数据库,缓存 ...
《沈剑架构师训练营》第8章 - 架构分层
40.分层:互联网分层架构方法论 no40:互联网分层架构的的本质是什么? 这是一个「数据移动」,然后「被处理」,被「呈现」的过程 no40:数据移动过程中最重要的两点是什么? 1.数据传输的格式 2 ...
《沈剑架构师训练营》第7章 - 架构解耦
34.解耦:配置中心,与配置架构演进. no34:配置文件架构有什么核心痛点? 1.上游痛:扩容的是下游,改配置重启的是上游(耦合,典型反向依赖) 2.下游痛:不知道谁依赖于自己(难以实施服务治理) ...
《沈剑架构师训练营》第5章 - 数据库架构
21.数据库:读性能要如何提升? no21:数据库工程架构,要设计些什么呢? 1.根据「业务模式」设计库表结构 2.根据「访问模式」设计索引结构 no21:数据库工程架构必须要考虑哪 5 个因素? 读 ...
《沈剑架构师训练营》第2章 - 接入层架构
6.接入层:反向代理,负载均衡,我有话要说 no6:代理和反向代理是什么? no6:一般用什么做反向代理? 软件层面:nginx/apache 操作系统层面:LVS 硬件:F5 no6:反向代理能解决 ...
《沈剑架构师训练营》第4章 - 微服务架构
14.服务化:微服务架构,究竟解决什么问题? no14:在服务化前后的互联网的常见架构示意图服务化前服务化后 no14:没有服务化前的痛点 1.代码到处拷贝 2.底层复杂性扩散 3.公共库耦合 4 ...
《沈剑架构师训练营》第6章 - 缓存架构
27.缓存:进程内缓存要怎么玩? no27:什么是进程内缓存?好处?不足? 定义将数据缓存在站点或者服务的进程内,如 map 或 leveldb,可存 json.html.object 等好处 1 ...
沈剑架构师训练营，最新金九银十JAVA面试合集
开篇介绍个人背景: 不说太多废话,但起码要让你先对我有一个基本的了解.本人毕业于浙江某二本院校,算是科班出身,毕业后就进了一家外包公司做开发,当然不是阿里的外包,具体什么公司就不透露了,在外包一呆就 ...
MySql数据库-58沈剑架构师之路
最近在看 "58沈剑架构师之路"的公众号,写的非常简练,干货很多.但里面也充斥了很多广告和管理类的文章,本文主要是对里面的数据库文章做一个汇总: InnoDB,5项最佳实践,知其 ...

《沈剑架构师训练营》第1章 - 技术选型

2、技术选型：创业初期，技术如何选型

3、技术选型：框架组件要不要自研，什么时候自研？

4、容量设计：流量高低，对架构究竟有什么影响？

5、伪分布式：你以为，多机就是分布式？

《沈剑架构师训练营》第1章 - 技术选型相关推荐

最新文章

热门文章