一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？

问题思考

什么是互联网公司？

互联网公司的准确定义，是没有的（我百度、谷歌了，都是些非权威解答）。

所以我就自己定义了一个：利用互联网提供服务，达到边际效应递减，并通过线上流量获利的企业与公司。

什么是大型？

又是一个很主观的词汇，老规矩，我来定义一个：流量超过1台服务器/数据库承载能力（假设已经优化到极致）时，你就步入某个程度的“大型”领域了。

遇到的挑战有哪些？

• 高性能

• 数据存储与一致性

• 服务与服务之间的关系

• 高可用与稳定性

下面，我要把题目反转，从有什么问题需要解决来反推解决手段，就是这么任性。

高性能

高并发读

无论是加缓存、动静分离、重写轻读的预算，本质上都是读写分离，专业名词就是CQRS（Command Query Responsibility Separation）。

高并发写

高可用

用户就是RMB，我们需要让系统变得更靠谱。

多副本、节点

鸡蛋不放在一个篮子里面，计算机系统要避免单点。

隔离、限流、熔断、降级

运维与监控

数据存储与一致性

事务一致性

多副本一致性

服务治理

服务尽量是可配置、可观测的。

这些点，其实现在有很多微服务基底可供选择，比如JAVA语言的Spring Cloud、Doubbo, Go语言的Go Kit、Micro。

当然，有条件的话，能直接上ServiceMesh是更好的，主流的服务网格框架有：Istio、Linkerd。

总结

其实，软件架构的进化方向，是一个全方位的平衡行为，做得好不好，就在于“度”的控制。

就好像，每引入一个节点、技术或服务，对于系统整体来说都是变数，都是风险点，怎么权衡利弊收益，怎么奔跑中换轮胎，都是值得思考的。

还有架构、技术选型的过程中，切忌按惯性思维去做抉择，而要进行“数据”的考量，比如社区活跃度、真实案例、压测报告、混沌测试，才能真正的反应真实情况，举几个例子：

上面这几点，都是有点与我们的架构思维惯性有点违和的行为，但是很有效果：