本周学习目标

互联网系统架构的演化及架构模式

内容概括

本周主要学习了互联网架构使用到的技术和发展演化过程。技术分类如下：

前端架构：app及web开发技术、浏览器及http优化技术、动静分离、CDN、图片服务、反向代理、DNS

网关及应用层架构：网关架构、负载均衡、动态页面静态化、业务拆分

服务层架构：微服务框架、分布式消息队列、分布式缓存、分布式一致性服务

存储层架构：分布式问价、分布式关系数据库、NoSql数据库

后台架构：大数据平台、搜索引擎、推荐引擎、数据仓库

运维与安全：数据采集与展示、数据监控与报警、攻击与防护、数据加密与解密

工作中的体会

互联网架构的演化过程也是自己实际工作中使用到的技术变迁过程。

从第一份工作在传统行业进行Web应用开发，使用单节点应用，部署的平台使用windows server、webLogic以及oracle，开发时使用大量的jsp及servlet，那时的应用完全不考虑性能，更多的是把精力放在如何把需求转化成设计实现出来，在开发中要花很多时间在调试页面上，前后端不分离的情况下，开发效率比较低，虽然花很多时间在页面布局上，但实际的兼容性却不好，所以会要求客户使用什么样的浏览器操作我们的系统。由于oracle功能强大，把很多的业务逻辑处理放在数据库层面上去做，运行大量的存储过程，还对数据库进行分级，底层Oracle计算结果传输给上层Oracle， 再进行进一步的聚合或者分组计算。

第二份工作用起了struct2，当时觉得比起spring MVC难用好多。开发团队对新技术还是比较感兴趣，针对当时要解决的问题使用了akka作为消息驱动的框架，kafka进行日志收集，solr进行检索。后来开始逐步尝试使用微服务，但排查问题困难的问题也逐步有所凸显。

第三份工作的时候，分布式服务已经非常流行了，微服务的拆分过于细腻，导致平台要管理20多个服务，但负责平台的后端开发人员只有三四名，这个时候开发效率就开始变得低下，新需求总会导致相关业务链都需要修改的情况，每个服务都有自己的模型，一个小的改动就要花很多的力气，还容易出错，因为开发人员很难本地调试这么多服务，还有可能影响别人的开发。服务拆分过细除了降低开发效率，运维也是异常的艰难，线上问题的排查会变得困难，一次接口调用链路很长，这中间还经过很多中间件，可能出问题的环节多。虽然有链路跟踪日志，但也是难以定位。目前我们又开始逐步合并服务，清理领域模型，去掉很多不合理的设计。

本周收获

互联网架构的演进过程就是不断解决问题的过程，在用户规模没有达到一定规模的时候，不要过度设计，会导致系统架构复杂，难以维护，且预判的一些设计并不符合发展。所以理解业务推进技术这一点很重要，作为开发人员一定要关注业务及业务发展的动向，而不是总觉得自己要设计一个完美的系统，因为需求的变化往往很快，所谓的完美可能很快的变得不适用现在的场景。