- 浏览: 565128 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (267)
- 随笔 (4)
- Spring (13)
- Java (61)
- HTTP (3)
- Windows (1)
- CI(Continuous Integration) (3)
- Dozer (1)
- Apache (11)
- DB (7)
- Architecture (41)
- Design Patterns (11)
- Test (5)
- Agile (1)
- ORM (3)
- PMP (2)
- ESB (2)
- Maven (5)
- IDE (1)
- Camel (1)
- Webservice (3)
- MySQL (6)
- CentOS (14)
- Linux (19)
- BI (3)
- RPC (2)
- Cluster (9)
- NoSQL (7)
- Oracle (25)
- Loadbalance (7)
- Web (5)
- tomcat (1)
- freemarker (1)
- 制造 (0)
最新评论
-
panamera:
如果设置了连接需要密码,Dynamic Broker-Clus ...
ActiveMQ 集群配置 -
panamera:
请问你的最后一种模式Broker-C节点是不是应该也要修改持久 ...
ActiveMQ 集群配置 -
maosheng:
longshao_feng 写道楼主使用 文件共享 模式的ma ...
ActiveMQ 集群配置 -
longshao_feng:
楼主使用 文件共享 模式的master-slave,produ ...
ActiveMQ 集群配置 -
tanglanwen:
感触很深,必定谨记!
少走弯路的十条忠告
互联网高可用架构为什么要服务化?
【服务化之前高可用架构】
在服务化之前,互联网的高可用架构大致是这样一个架构:
(1)用户端是浏览器browser,APP客户端
(2)后端入口是高可用的nginx集群,用于做反向代理
(3)中间核心是高可用的web-server集群,研发工程师主要编码工作就是在这一层
(4)后端存储是高可用的db集群,数据存储在这一层
更典型的,web-server层是通过DAO/ORM等技术来访问数据库的。
可以看到,最初都是没有服务层的,此时架构会碰到一些什么痛点呢?
【架构痛点一:代码到处拷贝】
举一个最常见的业务的例子->用户数据的访问,绝大部分公司都有一个数据库存储用户数据,各个业务都有访问用户数据的需求:
在有用户服务之前,各个业务线都是自己通过DAO写SQL访问user库来存取用户数据,这无形中就导致了代码的拷贝。
【架构痛点二:复杂性扩散】
随着并发量的越来越高,用户数据的访问数据库成了瓶颈,需要加入缓存来降低数据库的读压力,于是架构中引入了缓存,由于没有统一的服务层,各个业务线都需要关注缓存的引入导致的复杂性:
对于用户数据的写请求,所有业务线都要升级代码:
(1)先淘汰cache
(2)再写数据
对于用户数据的读请求,所有业务线也都要升级代码:
(1)先读cache,命中则返回
(2)没命中则读数据库
(3)再把数据放入cache
这个复杂性是典型的“业务无关”的复杂性,业务方需要被迫升级。
随着数据量的越来越大,数据库需要进行水平拆分,于是架构中又引入了分库分表,由于没有统一的服务层,各个业务线都需要关注分库分表的引入导致的复杂性:
这个复杂性也是典型的“业务无关”的复杂性,业务方需要被迫升级。
包括bug的修改,发现一个bug,多个地方都需要修改。
【架构痛点三:库的复用与耦合】
服务化并不是唯一的解决上述两痛点的方法,抽象出统一的“库”是最先容易想到的解决:
(1)代码拷贝
(2)复杂性扩散
的方法。抽象出一个user.so,负责整个用户数据的存取,从而避免代码的拷贝。至于复杂性,也只有user.so这一个地方需要关注了。
解决了旧的问题,会引入新的问题,库的版本维护与业务线之间代码的耦合:
业务线A将user.so由版本1升级至版本2,如果不兼容业务线B的代码,会导致B业务出现问题;
业务线A如果通知了业务线B升级,则是的业务线B会无故做一些“自身业务无关”的升级,非常郁闷。当然,如果各个业务线都是拷贝了一份代码则不存在这个问题。
【架构痛点四:SQL质量得不到保障,业务相互影响】
业务线通过DAO访问数据库:
本质上SQL语句还是各个业务线拼装的,资深的工程师写出高质量的SQL没啥问题,经验没有这么丰富的工程师可能会写出一些低效的SQL,假如业务线A写了一个全表扫描的SQL,导致数据库的CPU100%,影响的不只是一个业务线,而是所有的业务线都会受影响。
【架构痛点五:疯狂的DB耦合】
业务线不至访问user数据,还会结合自己的业务访问自己的数据:
典型的,通过join数据表来实现各自业务线的一些业务逻辑。
这样的话,业务线A的table-user与table-A耦合在了一起,业务线B的table-user与table-B耦合在了一起,业务线C的table-user与table-C耦合在了一起,结果就是:table-user,table-A,table-B,table-C都耦合在了一起。
随着数据量的越来越大,业务线ABC的数据库是无法垂直拆分开的,必须使用一个大库(疯了,一个大库300多个业务表 =_=)。
服务化解决什么问题?
为了解决上面的诸多问题,互联网高可用分层架构演进的过程中,引入了“服务层”。
以上文中的用户业务为例,引入了user-service,对业务线响应所用用户数据的存取。引入服务层有什么好处,解决什么问题呢?
【好处一:调用方爽】
有服务层之前:业务方访问用户数据,需要通过DAO拼装SQL访问
有服务层之后:业务方通过RPC访问用户数据,就像调用一个本地函数一样,非常之爽
User = UserService::GetUserById(uid);
传入一个uid,得到一个User实体,就像调用本地函数一样,不需要关心序列化,网络传输,后端执行,网络传输,范序列化等复杂性。
【好处二:复用性,防止代码拷贝】
这个不展开叙述,所有user数据的存取,都通过user-service来进行,代码只此一份,不存在拷贝。
升级一处升级,bug修改一处修改。
【好处三:专注性,屏蔽底层复杂度】
在没有服务层之前,所有业务线都需要关注缓存、分库分表这些细节。
在有了服务层之后,只有服务层需要专注关注底层的复杂性了,向上游屏蔽了细节。
【好处四:SQL质量得到保障】
原来是业务向上游直接拼接SQL访问数据库。
有了服务层之后,所有的SQL都是服务层提供的,业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话,可以由更资深的工程师维护,而不是像原来SQL难以收口,难以控制。
【好处五:数据库解耦】
原来各个业务的数据库都混在一个大库里,相互join,难以拆分。
服务化之后,底层的数据库被隔离开了,可以很方便的拆分出来,进行扩容。
【好处六:提供有限接口,无限性能】
在服务化之前,各业务线上游想怎么操纵数据库都行,遇到了性能瓶颈,各业务线容易扯皮,相互推诿。
服务化之后,服务只提供有限的通用接口,理论上服务集群能够提供无限性能,性能出现瓶颈,服务层一处集中优化。
【服务化之前高可用架构】
在服务化之前,互联网的高可用架构大致是这样一个架构:
(1)用户端是浏览器browser,APP客户端
(2)后端入口是高可用的nginx集群,用于做反向代理
(3)中间核心是高可用的web-server集群,研发工程师主要编码工作就是在这一层
(4)后端存储是高可用的db集群,数据存储在这一层
更典型的,web-server层是通过DAO/ORM等技术来访问数据库的。
可以看到,最初都是没有服务层的,此时架构会碰到一些什么痛点呢?
【架构痛点一:代码到处拷贝】
举一个最常见的业务的例子->用户数据的访问,绝大部分公司都有一个数据库存储用户数据,各个业务都有访问用户数据的需求:
在有用户服务之前,各个业务线都是自己通过DAO写SQL访问user库来存取用户数据,这无形中就导致了代码的拷贝。
【架构痛点二:复杂性扩散】
随着并发量的越来越高,用户数据的访问数据库成了瓶颈,需要加入缓存来降低数据库的读压力,于是架构中引入了缓存,由于没有统一的服务层,各个业务线都需要关注缓存的引入导致的复杂性:
对于用户数据的写请求,所有业务线都要升级代码:
(1)先淘汰cache
(2)再写数据
对于用户数据的读请求,所有业务线也都要升级代码:
(1)先读cache,命中则返回
(2)没命中则读数据库
(3)再把数据放入cache
这个复杂性是典型的“业务无关”的复杂性,业务方需要被迫升级。
随着数据量的越来越大,数据库需要进行水平拆分,于是架构中又引入了分库分表,由于没有统一的服务层,各个业务线都需要关注分库分表的引入导致的复杂性:
这个复杂性也是典型的“业务无关”的复杂性,业务方需要被迫升级。
包括bug的修改,发现一个bug,多个地方都需要修改。
【架构痛点三:库的复用与耦合】
服务化并不是唯一的解决上述两痛点的方法,抽象出统一的“库”是最先容易想到的解决:
(1)代码拷贝
(2)复杂性扩散
的方法。抽象出一个user.so,负责整个用户数据的存取,从而避免代码的拷贝。至于复杂性,也只有user.so这一个地方需要关注了。
解决了旧的问题,会引入新的问题,库的版本维护与业务线之间代码的耦合:
业务线A将user.so由版本1升级至版本2,如果不兼容业务线B的代码,会导致B业务出现问题;
业务线A如果通知了业务线B升级,则是的业务线B会无故做一些“自身业务无关”的升级,非常郁闷。当然,如果各个业务线都是拷贝了一份代码则不存在这个问题。
【架构痛点四:SQL质量得不到保障,业务相互影响】
业务线通过DAO访问数据库:
本质上SQL语句还是各个业务线拼装的,资深的工程师写出高质量的SQL没啥问题,经验没有这么丰富的工程师可能会写出一些低效的SQL,假如业务线A写了一个全表扫描的SQL,导致数据库的CPU100%,影响的不只是一个业务线,而是所有的业务线都会受影响。
【架构痛点五:疯狂的DB耦合】
业务线不至访问user数据,还会结合自己的业务访问自己的数据:
典型的,通过join数据表来实现各自业务线的一些业务逻辑。
这样的话,业务线A的table-user与table-A耦合在了一起,业务线B的table-user与table-B耦合在了一起,业务线C的table-user与table-C耦合在了一起,结果就是:table-user,table-A,table-B,table-C都耦合在了一起。
随着数据量的越来越大,业务线ABC的数据库是无法垂直拆分开的,必须使用一个大库(疯了,一个大库300多个业务表 =_=)。
服务化解决什么问题?
为了解决上面的诸多问题,互联网高可用分层架构演进的过程中,引入了“服务层”。
以上文中的用户业务为例,引入了user-service,对业务线响应所用用户数据的存取。引入服务层有什么好处,解决什么问题呢?
【好处一:调用方爽】
有服务层之前:业务方访问用户数据,需要通过DAO拼装SQL访问
有服务层之后:业务方通过RPC访问用户数据,就像调用一个本地函数一样,非常之爽
User = UserService::GetUserById(uid);
传入一个uid,得到一个User实体,就像调用本地函数一样,不需要关心序列化,网络传输,后端执行,网络传输,范序列化等复杂性。
【好处二:复用性,防止代码拷贝】
这个不展开叙述,所有user数据的存取,都通过user-service来进行,代码只此一份,不存在拷贝。
升级一处升级,bug修改一处修改。
【好处三:专注性,屏蔽底层复杂度】
在没有服务层之前,所有业务线都需要关注缓存、分库分表这些细节。
在有了服务层之后,只有服务层需要专注关注底层的复杂性了,向上游屏蔽了细节。
【好处四:SQL质量得到保障】
原来是业务向上游直接拼接SQL访问数据库。
有了服务层之后,所有的SQL都是服务层提供的,业务线不能再为所欲为了。底层服务对于稳定性的要求更好的话,可以由更资深的工程师维护,而不是像原来SQL难以收口,难以控制。
【好处五:数据库解耦】
原来各个业务的数据库都混在一个大库里,相互join,难以拆分。
服务化之后,底层的数据库被隔离开了,可以很方便的拆分出来,进行扩容。
【好处六:提供有限接口,无限性能】
在服务化之前,各业务线上游想怎么操纵数据库都行,遇到了性能瓶颈,各业务线容易扯皮,相互推诿。
服务化之后,服务只提供有限的通用接口,理论上服务集群能够提供无限性能,性能出现瓶颈,服务层一处集中优化。
发表评论
-
HTTPS的加密原理解读
2021-12-31 11:25 275一、为什么需要加密? 因为http的内容是明文传输的,明文数据 ... -
容器技术的基石: cgroup、namespace和联合文件系统
2021-12-09 10:47 673Docker 是基于 Linux Kernel 的 Names ... -
链路追踪skywalking安装部署
2021-10-21 12:06 787APM 安装部署: 一、下载 版本目录地址:http://a ... -
自动化运维 Ansible 安装部署
2021-08-20 19:06 816一、概述 Ansible 实现了批量系统配置、批量程序部署、 ... -
Linux 下 Kafka Cluster 搭建
2021-07-08 11:23 950概述 http://kafka.apachecn.org/q ... -
ELK RPM 安装配置
2021-06-22 18:59 592相关组件: 1)filebeat。用于收集日志组件,经测试其 ... -
在Kubernetes上部署 Redis 三主三从 集群
2021-03-10 16:25 622NFS搭建见: Linux NFS搭建与配置(https:// ... -
docker-compose 部署ELK(logstash->elasticsearch->kibana)
2020-11-11 18:02 1545概述: ELK是三个开源软件的缩写,分别表示:elastic ... -
Kubernetes1.16.3下部署node-exporter+alertmanager+prometheus+grafana 监控系统
2020-10-28 10:48 1028准备工作 建议将所有的yaml文件存在如下目录: # mkd ... -
Linux NFS 搭建与配置
2020-10-21 17:58 402一、NFS 介绍 NFS 是 Network FileSys ... -
K8S 备份及升级
2020-10-20 15:48 850一、准备工作 查看集群版本: # kubectl get no ... -
API 网关 kong 的 konga 配置使用
2020-09-23 10:46 4078一、Kong 概述: kong的 ... -
云原生技术 Docker、K8S
2020-09-02 16:53 531容器的三大好处 1.资源 ... -
Kubernetes 应用编排、管理与运维
2020-08-24 16:40 557一、kubectl 运维命令 kubectl control ... -
API 网关 kong/konga 安装部署
2020-08-25 17:34 553一、概述 Kong是Mashape开 ... -
Linux 下 Redis Cluster 搭建
2020-08-13 09:14 699Redis集群演变过程: 单 ... -
Kubernetes离线安装的本地yum源构建
2020-08-08 22:41 491一、需求场景 在K8S的使用过程中有时候会遇到在一些无法上网 ... -
Kubernetes 证书延期
2020-08-01 22:28 426一、概述 kubeadm 是 kubernetes 提供的一 ... -
kubeadm方式部署安装kubernetes
2020-07-29 08:01 2319一、前提准备: 0、升级更新系统(切记升级一下,曾被坑过) ... -
Kubernetes 部署 Nginx 集群
2020-07-20 09:32 824一.设置标签 为了保证nginx之能分配到nginx服务器需要 ...
相关推荐
### 互联网架构为什么要做服务化 #### 一、服务化前的互联网高可用架构及其痛点 在服务化之前,互联网的高可用架构大致遵循以下结构: 1. **前端**: 用户端包括浏览器(Browser)和APP客户端。 2. **后端入口**: 高...
### 2018大型互联网架构演变历程:以淘宝为例 #### 一、背景与重要性 随着互联网行业的快速发展,大型互联网企业的系统架构也在不断进化和完善。这些变化不仅仅是技术层面的进步,更是对整个互联网产业发展方向的...
在大型互联网架构设计中,我们面对的是海量的数据处理、高并发访问、以及快速迭代的产品需求。这要求架构设计师具备深厚的技术底蕴和灵活的创新思维。本文将深入探讨互联网架构的关键要素,包括技术选型、生命周期...
在工业互联网体系架构中,工业云提供了虚拟化、弹性伸缩、资源池化等云计算服务,使得工业应用能够更加灵活和高效。 云计算则是通过网络将计算资源(包括服务器、存储、数据库、网络、软件等)集中起来,构成一个...
### 互联网分层架构之-DAO与服务化 #### 一、引言 随着互联网业务的不断扩张与深化,单一的系统已经无法满足日益增长的需求。为了更好地支持复杂的业务场景,提升系统的稳定性和扩展性,分层架构逐渐成为了业界...
工业互联网平台是现代制造业的重要组成部分,它通过将物联网技术、大数据分析、云计算和人工智能等先进技术融合,构建了一个连接设备、系统、供应链以及人员的智能化网络。"工业互联网平台白皮书+体系架构"旨在深入...
- **营销系统改造**:面对传统营销系统的局限性和挑战,企业可以通过重构系统架构,采用服务化的方式打破信息孤岛,实现全渠道销售和服务。例如,通过引入订单处理中心、促销活动管理系统等组件,提高系统的并发性能...
这一过程中,数据成为驱动生产和服务创新的核心要素,推动着制造业向服务化、定制化和绿色化发展。 工业互联网体系架构1.0已经取得了显著的进展,为后续的2.0版本奠定了基础。从1.0到2.0的演进,主要体现在对工业...
为了最大化利用有限的计算资源,互联网架构设计中通常会采用以下几种策略: 1. **系统容量管理**:通过流控、请求排队等手段防止系统过载。 2. **连接控制**:采用短连接和长连接相结合的方式,确保连接的有效管理...
这些原则指导着我们决定何时引入DAO层,何时进行服务化,何时抽取通用中台业务,以及何时进行前后端分离。然而,这些决策应当基于业务的发展阶段、规模、数据量和并发量等因素,不能轻易地下断言。 总结来说,...
3. 互联网架构:互联网架构通常是指支持大规模在线服务的基础设施设计,包括网络拓扑、数据中心布局、CDN内容分发网络等。对于像新浪、百度这样的搜索引擎或新闻平台,高并发处理能力和快速的内容分发是关键;而对于...
- **Dubbo**:一款高性能、轻量级的开源微服务框架,用于构建服务化应用。 - **Spring Boot**:简化新Spring应用的初始搭建以及开发过程的框架,旨在简化Spring应用的配置。 - **Spring MVC**:Spring框架的一个...
4. **服务化转型**:通过实时监测产品运行,提供远程服务,实现企业服务化转型。 工业互联网与智能制造密切相关,前者是后者的关键基础。智能制造依赖于先进的制造技术和工业互联网提供的信息技术,包括智能传感...
互联网软件架构将向着支持服务化、模块化以及云计算的方向发展,以实现更加智能、高效和稳定的软件应用。 互联网软件开发架构的研究与设计,不仅关系到软件产品的质量与性能,也对整个信息社会的发展有着深远的影响...
在构建中小型互联网公司的后台服务架构与运维架构的过程中,我们需要考虑一系列关键技术和实践。"龙果学院"的这个视频教程提供了从零开始搭建整个系统的详细步骤,涵盖了Spring、Spring Boot和Dubbo等主流技术栈。...
互联网架构中,静态页面和动态页面是两个不同的概念。静态页面是指互联网架构中几乎不变的页面,例如首页、HTML页面、JS/CSS样式文件、jpg/apk等资源文件。这些页面变化频率很低,适合使用静态页面加速技术来提高...
淘宝的架构是电子商务领域的经典案例,它以微服务为基础,实现了服务化拆分。使用TDDL(淘宝数据访问层)进行数据访问,通过RocketMQ处理消息队列,实现异步通信和解耦。此外,淘宝的HSF(高性能服务框架)用于提供...
在互联网技术领域,架构设计是构建高效、稳定且可扩展系统的基石。本文将深入探讨互联网技术架构设计的一些核心原则和概念,旨在提升架构思维并优化系统设计。 首先,我们需要理解“道”与“术”的关系。道是事物的...