互联网架构演进过程能力目标能够多维度了解近几年互联网的趋势（以电商淘宝为例）能够拥有初步了解各个阶段的技术解决方案Architect课程的缩影，可以了解整个课程题目在架构体系中的位置1.业务架构1.1单体模型早期的系统多为单体业务，逐一扩展.该系统也大多呈现为独立运行的多个mvc。各自发挥。以电子商务为例，可能会继续按照B2B、B2C、C2C的方式进行拓展。每个业务都有一个系统，每个系统都有一个维护团队。1）方案代理层设置不同的二级域名，如b2b.abc.com、b2c.abc.com，分布到不同的服务器上，出现新的业务线时疯狂扩容重复开发：同一个功能可能在不同的业务项目中重复开发，如短信发送、支付、财务统计等1.2中台战略1.2.1概述中台于2015年由阿里提出，阿里分享了业务技术部的组建过程。中泰是企业架构，而非纯技术层面。目前几乎各大电商都在进行中台的建设。中台并非新鲜事物，实际上是“共享”理念在业务、制度、组织架构上的落地和落地。关键词：共享、节约成本、协同1.2.2背景单一的业务模型带来诸多问题：1）技术架构：部分功能相同，重复建设和维护导致各个团队重复投资业务系统之间的集成与协同高成本不利于基础业务的沉淀和可持续发展2）组织架构方面：部门往往每个项目一个团队，单一模式。团队随着项目疯狂扩张，利用率低下。以中台类比：在中台模式下，基础业务也下沉到技术部门，甚至通过技术逆转业务的正向发展。下层业务，变化不大的业务不断沉淀，接口像滚雪球一样越来越完善。上层业务，业务模型和运营产品相关的系统变化快，底层接口可以封装组合。1.2.3案例基于经典电商以台湾分工为例：1）业务中的平台是基于公共服务的沉淀，需要积累一些基础的业务服务。这些服务在B2B、B2C等系统中都有，而且都是一样的。商品中心：商品、类目、sku、spu交易中心：订单、状态转移、物品、支付营销中心：促销、优惠券、活动会员中心：账号、基本信息、收货地址、门店业务信息仓储中心：仓库、库存物流中心：配送信息、独立物流或外部物流对接……2）技术平台基础与业务无关，技术内容可在各个团队间共享。基础设施：核心类库、公共框架、基础服务、服务治理框架中间件：分布式缓存、分布式消息、数据存储（db、nosql）、分布式文件、分布式调度自动化运维：监控中心、资源管理、配置中心、发布中心、日志平台自动化测试：任务协同、基础测试、性能测试、接口测试、持续集成（有的公司会提炼出一个运维平台，将开发层和系统层的内容分开）。..3)数据中心数据中心既不是数据平台也不是数据仓库。三者之间存在差异。例如：数据平台可以理解为数据库，数据仓库可以比作报表。数据中心更贴近上层业务，具有业务属性。它还以接口的形式提供对其他上层业务线的持续调用。数据抽取：提供db、nosql、logs等多种来源的抽取接口数据接口：为上层业务提供定制化的业务数据接口数据分析：行业分析决策，数据驱动运营人工智能：用户画像、商品推荐可视化：数据大屏、信息展示、活动报表等。4）服务接入层为大中台、小前台前台、B2B、电子商务中直接面向用户的B2C。现有的商业模式、流程等根据市场及时调整，变化非常快。新业务线可快速落地，无需重复开发底层中台业务，调用中台接口组装即可。总结思考单一的商业模式容易引发哪些问题？去中心化是什么概念？它带来了哪些挑战？2.数据结构2.1单一数据库早在2003-2004年淘宝V1.0就使用mysql，V1.1被oracle取代，直到2007年数据库迁移到mysql。这个阶段往往导致追oracle等商业大型db（淘宝v1.1，mysql→oracle）1）方案javaweb项目通过jdbc直接连接单个数据库，一起读写，机器io和单数据库cpu性能即将达到上限数据库：mysql、oracle、sqlserver、db2等（主题：mysql性能调优）持久层框架：jdbc、hibernate、jpa、mybatis（主题：源码分析mybatis)2.2主从从oracle读写淘宝交换在mysql的过程中，实现了主从库部署和读写分离。1）解决方案javaweb应用层连接多个数据库，数据库之间形成主从关系。主库写，从库读。读写压力分散数据库集群：一主多从，双主单写（问题：Mysql千亿在线扩容实践）应用层开发：多数据源支持，spring多数据源2）特点数据延迟：从主库和从库之间的数据需要通过网络传输，这必然会拖延开发层面：开发框架需要有多数据源的支持，数据源的自动切换单库瓶颈：商家越来越多，桌子越来越多。一个数据库中有数百个表。数据局限性：仍然无法解决单表大数据的问题。比如订单累计达到1亿。即使在从库中，关联查询仍然极其缓慢。2.3分库分表2004-2007，淘宝V2.1，分库。1）方案主从库的编写还是有一个统一的主库入口。随着业务量的增加，继续细粒度拆分业务分库：订单库、产品库、活动库、会员库横向分表：（拆分记录）3个月内订单，半年内订单，moreordersvertically分表：（去掉字段）name和phone一张表，info和address一张表，两张表id相同（主题：日产千万订单背后的痛点和技术突破)2)特征分库：不同的数据库，所以不能使用数据库事务，分布式事务的效果也不理想，经常使用幂等和最终一致性方案。（主题：多服务间分布式事务一站式解决方案，业务幂等性技术架构体系）分片表：拆解和重新聚合是一对矛盾体。比如按照订单时间维度的分片表，需要用户进行排序统计变得异常困难。中间件：Sharding-JDBC（主题：分库分表下每天产生亿级订单的痛点和架构）、Mycat、Atlas2.4缓存2006-2007、淘宝V2.2架构、分布式缓存Tair介绍。1）解决方案数据库往往是系统的瓶颈。根据数据的冷热划分，类目、商品基本信息等热点数据放在缓存中，其他数据延迟加载。Ehcache：非分布式，简单，易维护，通用性性能可靠，纯内存，集群需要客户端实现，无持久化实际的缓存代理方案，高层使用Twemproxy）2）特点缓存策略：冷热数据的存储，cache和db的边界需要架构师把控，重度依赖可能会出问题（memcache导致db高压case；redis短信平台故障case）Cachetrap:breakdown(singlekeyexpires)、穿透（不存在的key）、雪崩（多个key同时过期）数据一致性：在cache和db之间保存了两份相同的数据，自然就带来了一致性的问题（话题：redishigh级技术分析）2.5数据多样化在一个网站中，数据库和缓存只是一种基本的存储方式。除了这些，随着网站架构的发展，其他形式的存储结构也相继出现：2006-2007，淘宝V2.2，分布式存储TFS，分布式缓存Tair，V3.0加入nosqlCassandra，搜索引擎升级数据库全文搜索→搜索引擎、本地上传+nfs→分布式文件系统2.5.1分布式文件商品图片、上传文件等hdfs：大数据下的分布式存储（主题：ApacheDruid搭建大数据实时监控系统，基于Flink的打车平台实时流数据分析）fastdfscephFs（主题：无限容量云盘分布式存储技术解决方案ceph）2.5.2nosqlredis经典缓存，mongodb在上一节已经介绍过（主题：mongodb海量数据生产及扩容实践）hbasetidb（题目：TiDB亿级订单数据子二次响应查询方案）2.5.3搜索引擎搜索引擎：lucene、solr、elasticsearch（题目：电商终极搜索ElasticStack）2.5.4架构特点开发框架支持：存储数据多样化，要求开发框架架构提供多样化数据维护：各种数据服务器运维需求增加，机器数据维护和容灾工作量增加数据安全：多数据存储权限、授权和访问隔离需要注意的总结思考的常用数据库有哪些？持久层框架呢？什么是分库，什么是分表？什么是子表？缓存有哪些问题，有哪些场景？3.应用架构3.1单机调优早年项目大多使用mvc开发1)特点每个项目都有mvc结构，部署在应用服务器（tomcat、jboss、websphere、weblogic）上。（主题：tomcat源码分析）随着业务的扩展和需求的迭代，项目越来越大，一个war包动辄上百兆。提倡调优，jvm单节点调优甚至接近强迫症的地步。（主题：jvm性能调优）3.2动静分离早年的Apache+tomcat，后来几乎被nginx一统天下。（前后端开发模式的演变：mvc页面嵌套→接口）1）方案静态响应：tomcat一般响应静态文件，提取静态文件，直接响应nginx动态代理：转发后端api通过代理到tomcat应用机2）特性开发层次调整：项目结构同步调整，由原来集成mvc改为后端api+前端形式。前后台协同：前后端分工更加清晰，并行开发，独立部署，但也带来了接口协同、约定等通信问题跨域问题：如果后端的域名end和前端不同，可能会出现跨域问题（head、jsonp等方式可以解决）。3.3分布式服务拆分开始！纯动静分离只是解决了自身服务的项目结构。调用跨项目接口时，必须经过restrequest，不利于服务间的交互。淘宝V3.0，HSF出现，面向服务，架构师忙着梳理SOA和系统的关系。1）程序公共服务：将重复开发的基础服务抽取出来，形成服务中心，避免重复造轮子，降低成本，架构团队的产生。独立性：每个服务独立部署和升级，粒度更细，低耦合，高内聚SOA理念诞生：服务治理的范围，注重服务之间的拆分和统一接口2）异步技术手段：rabbitmq（主题：滴滴打车超时架构设计）rocketmq（课题：滴滴打车排队原理及分析）kafka（课题：海量订单数据同步）rpc：dubbo（课题：dubbo核心源码分析，zookeeper源码分析）rpc框架（课题：rpc核心源码和手写Rpc，netty通信和进阶）3）特性边界控制：服务粒度、拆分和公共服务细化需要架构师的整体把控。糟糕的设计很容易导致混乱的部署和升级：服务数量增加，手动部署变得不现实，必须使用自动化运维（题目：高效运维，docker、k3s、jenkins、Apollo应用发布实战)服务可用性：tunedmicro由于服务需要被多个上层业务共享，所以可用性级别变高。一旦宕机，就是灾难性的熔断和限流：做好服务熔断和限流，谨防单点服务瓶颈导致整个系统瘫痪。短信提醒失败不影响下单。（主题：云阿里巴巴，sentinel限流）3.4微服务1）解决方案微服务是基于SOA的思想，进一步细化了系统的粒度，作为一种手段而诞生的。实现集中化，将各个中心和前端业务拆解成多个小的服务单元。2）技术手段微服务经历了从1.0（云）到2.0（服务网格）的演进，目前企业中的主流方案仍然是云全家桶springcloud（主题：springcloud微服务前沿技术栈、spring、springboot源码分析）3）特征服务拆分：粒度越小越好。太小会带来部署、维护等一系列成本的增加。（课题：skywalking微服务监控）接口约束：随着系统数量的增加，各个服务接口的标准化越来越重要。需要统一的服务接口规范来推动企业消息总线的建设。权限约束：接口不能随意调整。良好的权限控制，借助oauth2等手段，实现服务间的权限认证。总结与思考如何理解微服务与SOA、分布式的关系？常用的分布式服务框架有哪些？4.部署架构4.1对于小型单机网站，还有人在用阿里云的小项目。1）该方案的单机性能很快达到上限，意味着资源不足，然后开始升级配置，推动高端机的发展，成本高。一机连线，简单易操作。（主题：tomcat源码分析）资源争夺：在业务发展初期尚可支撑，但随着访问量的增加，单机性能很快就会成为系统瓶颈。4.2稍微大一点的系统，有角色划分，剥离掉数据库、缓存、消息等中间件，单独部署一台机器1）解决方案多机：tomcat和mysql各有自己独享的机器资源针对性扩展：tomcat应用机器更注重cpu的计算和内存，mysql更注重io和磁盘性能，根据各自情况进行扩容（题目：架构设计基础保障）2）特点数据维护：可以提取单独的dba到维护数据库服务器数据安全：需要跨机访问数据库，链接密码需注意防止泄露4.3应用集群2004-2005，淘宝V2.0，EJB为核心。V2.1架构下，引入spring框架，向轻量级和集群化迈进1）解决方案apache：早期负载均衡方案，性能一般nginx：7层代理，性能强大，配置简单。用户流控）haproxy：性能同样可靠，可作为七层或四层代理。lvs：4层代理，性能最强，linux集成，配置麻烦（主题：lvs+keepalived高可用部署实战）f5：4层，硬件负载，有钱有势的最佳选择2）特性sessionretention:集群环境下，用户登录需要分布式session作为支持（题目：多维系统下单点登录深入讲解）分布式协作：分布式环境下对资源的加锁超出了线程锁的范畴，并上升到一个分布式锁调度问题：scheduler不能部署在多台机器上，容易重复运行，除非使用分布式调度，比如elastic-job机器状态管理：多台应用机器的状态检测和更换需要及时。一般niginx层做failover服务升级：滚动升级成为可能，灰度发布（主题：不可忽视的灰度发布）日志管理：日志文件分散在各个机器上，促进集中日志平台的产生（主题：-集中日志平台的深度应用）4.4多层代理1）方案机器规模进一步增大，静态和动态都有多个nginx负载，入口统一交给lvs负载。多层代理形成。2）特性机房受限：lvs还是单节点，即使keepalived做到了高可用，流量还是需要从唯一入口进入。4.5远程访问淘宝V2.1时代，使用自己的淘宝CDN。部署同一个系统的多个副本，分布到异地的多个机房，或者电信、移动等多个网络。不同地点、不同网络接入的用户，有不同的接入入口和选择。1）方案dnspolling：通过配置多个IP将服务部署到多个机房，通过dnspolicypolling进行调用，实现机房级别的扩容。CDN：就近原则使用户可以在最近的机房访问相关资源，而且投资太大，需要付费购买其他方。2）特性基本解决了机器部署的扩展问题。随着业务的发展，扩缩容变得困难，推动了资源调度技术的发展。4.6云平台为应对中心化建设和微服务数量激增，部署和运维支撑正在同步发生变化。面临微服务快速部署、资源弹性伸缩等挑战，容器化、云化正在推进。案例：服务有几十万，推广期间临时扩容部分微服务。1）方案虚拟化：vm方案、Openstack、Vmware、VirtualBox容器化：docker编排：swarm、k8s、k3s（题目：运维篇docker、k8s深入原理与应用）云化：容器化解决资源快速伸缩，但仍需要企业准备大量机器资源。推动私有云向企业云演进2）特征资源预估：关注资源的回收利用，减少资源闲置和浪费，如推广结束后及时回收。运维要求：对运维层面的支持要求高，门槛相对较高预估风险：云故障造成的损失不可估量。（openstack崩溃事故案例）总结与思考常见的代理服务器有哪些？每个属于网络的哪一层？docker的编排工具是什么？架构思维任何系统的形成都不是一蹴而就的。随着访问量和数据量的增加，业务需求正在推动技术架构的发展和变革。知行合一，做之前先考虑原意优于定制，约定大于配置。一切最终都会化为乌有。扩容不要胡思乱想，但也不要以为100年后就没有最好的了，只有最合适的就够了。你玩的越多，风险就越大。简单而美丽
