从程序员进阶到架构师，最全进阶详解（下篇）-大型网站架构篇

时间：2023-05-30 13:36:02 | 来源：网站运营

时间：2023-05-30 13:36:02 来源：网站运营

从程序员进阶到架构师，最全进阶详解（下篇）-大型网站架构篇：

从程序员到架构师进阶，将涉及到数据结构和算法，Java编程语言掌握，Javaweb核心技术，数据库，Java框架与必备工具，系统架构设计等六大环节。

一共分为上篇、中篇、下篇，这是程序员进阶到架构师系列篇的最后一篇，重点讲解大型网站系统架构设计。

优知学院：从程序员进阶到架构师，最全进阶详解（上篇）

优知学院：从程序员进阶到架构师，最全进阶详解（中篇-架构进阶）

面向服务的体系架构（SOA）

其实面向服务架构 SOA 思想概念的提出已不是什么新鲜事，大概在10年前就有不少相关书籍介绍过。当时 Java 企业应用领域 J2EE 依然是主流，应用程序被部署在庞大统一的符合 J2EE 规范的容器中运行，在单一进程中提供所有的功能。

早期的 SOA 通常和另外一个术语关联在一起ESB（企业服务总线）。 当时在 SOA 的实施思路上无一例外的选择了 ESB 模式来整合集成大量单一庞大的应用，以保护企业前期投入成本。因此 ESB 其实是 SOA 特定历史阶段的一种实现方式。

然而，如今谈到SOA服务架构的场景，最具有代表性的的肯定就是阿里集团下的：淘宝、支付宝等大数据、多个的业务模块，成百上千的工程师一起开发的业务的场景。

正确的SOA架构应该怎样定义？







SOA(Service-Oriented Architecture)，即面向服务的架构，SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

面向服务架构，本质上就是将之前的单体应用拆分成多个应用，每个应用之间是通过分布式服务框架或者是一些RPC的框架进行通讯交互，需要服务化提供的三大能力：

第一，是提供的物理层面对业务分解抽象的能力

第二，是解决了系统的一个水平扩展问题。

第三，是能够让一家公司具备百人以上的团队进行协作开发的能力，即提高我们的开发效能。

面向服务设计，因为涉及到分布式这一块，技术涉及非常多，主要包括像分布式服务框架、注册中心，一些序列化化、反序列化的知识以及RPC的框架，服务化之后很重要一点就是需要有服务治理，需要有负载均衡、软负载，需要有配置中心、消息中心等等。每一种技术都是一个比较深的主题，大家可以自行研究一下这方面的技术。

也可以参考阿里开源出来的Dubbo和HFS，阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，以及SOA服务治理方案。

大型网站架构设计能力

其实就是要很清楚整个技术架构的演变历程，知道每个阶段的瓶颈在哪里，以及对应的解决方案。

随着互联网技术迅速发展和演变，不断改变的商业化应用系统越来越复杂，由单一的应用架构到垂直的应用架构，但还是面临的扩容的问题。流量分散在各个系统中，虽然体积可控，但对开发人员和维护人员带来极麻烦。此时，将核心的业务单独提炼出来作为单独的系统对外提供服务。达成业务之间复用，系统也将演变成分布式系统架构。分布式架构是各组件分布在网络计算机上、组件之间仅仅通过消息传递来通信并协调行动，与上面提到的SOA服务架构一脉相承。

大型网站最终都会走向大型分布式业务场景

搭建分布系统的基础设施

缓存搭建

分布式缓存搭建 memcached ,redis（推荐），动态、静态数据的缓存，以及配合单点登录的使用等。

CDN搭建

为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。

持久化储存搭建

Hbase、MySQL、Redis传统的IOE方案： IBM小型机Oracle数据库 EMC持久储存成本很高。传统的数据库提供完整地acid功能，并且提供丰富的内连接外连接关联查询等功能。但是，对于高并发应用来说，有的时候会牺牲关联查询事务数据一致性（降级为最终一致性）。

Hbase有更好地伸缩能力，更适合海量数据储存。并发写入十分出色，能够支持多regionserver同时写入。但是其本身对于查询的支持力度有限，比如group by order by join等。

Redis是一个key-value类型的数据库，能够支持更高的并发量，而且支持的数据类型也比其他的key-value数据库的数据类型多。

消息系统搭建

目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。

使用场景也是非常多：异步处理，应用解耦，流量削锋和消息通讯四个场景。

还有搜索引擎系统、文件系统、日志系统、数据仓库等。

分布式文件系统和分布式数据库

一般先分库，如果分库后查询仍然慢，于是按照分库的思想开始做分表的工作数据库采用分布式数据库（所有节点的数据加起来才算是整体数据），文件系统采用分布式文件系统任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。

分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

比如淘宝中期开始的数据库端按照业务垂直拆分：按照业务交易数据库、用户数据库、商品数据库、店铺数据库等进行拆分。

还有就是水平扩展，分库分表，再结合读写分离一起。当然，分库分表需要涉及到对应的SQL路由规则主库备库等，淘宝设计了一套TDDL来解决这些问题，应用端只需配置对应的规则即可，对应用端的没有任何侵入的设计。

采用sql和nosql混搭搭建

随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

代码业务拆分

纵向拆分：

将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统、纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：

将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务、横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

还要考虑机房容灾以及系统运维监控等。

如果对大型网站分布式架构有兴趣，也可以查看官网文章淘宝发展历程最具决定性的一次技术架构演变，文章里有详细的介绍淘宝的整个架构演变历程和步骤。




以上就是完整的从程序员进阶到架构师的上、中、下篇内容，更多架构相关的内容请关注优知学院公众号获取。




作者：IT人升职加薪进阶站 优知学院 (www.youzhixueyuan.com，微信公众号：youzhixueyuan）创始人陈睿|mikechen,历任淘宝高级软件工程师、盛大架构师、百度研发经理、携程定制旅游CTO，分享职场、架构、CTO进阶经验和心得。