架构师之路-创业互联网公司如何搭建自己的技术架构
适用范围
本文主要针对中小型互联网公司,特别适用于手机APP或者pc的后台架构,基本可以支撑5万日活
本文会对可能用到的相关技术进行技术选型的说明,以及技术的架构介绍,技术架构的介绍课程后面有地址,可以点进去查看。
技术指标
说一下一些技术指标的计算过程可以作为其他同学的参考
QPS, 如果是5万日活,使用集中在每天的4小时,每个用户大概产生100的请求,那么平均下来,我们系统大概应该支撑的请求为:50000 * 100 / (4 * 60 * 60) = 350 qps/s
业务数据 业务量,我们自己是新闻业务,可能会有其他的业务,比如游戏,商城等等,基本每天新增的业务数据都会在同一个量级, 每日10000, 另外跟用户相关的信息也是比较大的一块,比如用户的订阅等行为,一共5万的用户,保存相关信息可能大概需要100条的数据。
缓存大小 主要业务数据和用户相关的热点数据限时保存在缓存中, 大概需要5个G左右。
日志大小 用户日志和请求日志。 大概每天3个G左右
技术架构
整体架构因为是小公司,我们基于阿里云来搭建,对图中的内容和技术选型进行一下说明:
负载均衡
可选方案: SLB, Nginx.
SLB要收钱,但是比较便宜,有保证,不会挂。 但是可配置的很少,不能根据域名做ip映射
Nginx, 没啥缺点,需要一定的知识。
建议: SLB + Nginx, SLB绑定域名作为统一的入口,然后每个服务器上再搭建Nginx.
CDN
用于缓存静态文件等等。 七牛和阿里的都还可以。
七牛要做的久一点, 各种图片处理的接口要完善一些
阿里的CDN要稍微好一点点, 但是没有不安全的访问方式,访问稍微没有那么灵活。 图片处理功能弱一点。
分布式调用框架
目前可选的有ZK + dubbo. ZK + Motan, ZK + dubbox, edas。
dubbo, 阿里的服务治理框架,已经不维护了,切换反应有点慢
dubboX, 当当基于dubbo搞的,还在维护可以一用,推荐。
Motan, 微博的服务治理矿建, 刚开源,需要学习一下, 推荐。
Edas, 阿里云服务,要收钱,侵入型很强,不推荐
MQ
可选的有: ActiveMQ, rocketMQ, robbitMQ,Kafka
各有好处, 但是考虑到运维的难度,推荐rocketMQ。
Redis
用来做缓存, 自建成本有点高,需要Codis, 分片,集群,主从等等,很麻烦。 建议直接用阿里的
数据库
主要基于读写分离和主从复制考虑,目前可以自建和选用阿里的DRDS。
DRDS 要花钱,成本较高,没有必要
自建, 不用中间件,直接1写2只读, 然后配置读写分离的数据源,内网SLB进行读集群。解决之。
搜索
建议ELK, 可以自动同步数据库,除了搜索引擎的功能外,还可以做日志搜索,监控系统。
一些典型的业务场景说明
把业务底层做成SOA模块,通过分布式调用框架对外提供服务。
后期进行SOA到微服务的改造都会涉及。
单独做一个小的系统来运行定时任务
热点数据放缓存,然后通过MQ来更新缓存
日志等数据有必要可以考虑上个Mongo
可以参考:http://www.roncoo.com/course/view/ae1dbb70496349d3a8899b6c68f7d10b

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
如何设计高可用的微服务架构
要点 动态的环境和分布式的系统,比如微服务,它们出现故障的几率更大。 发生故障的服务应该被隔离开来,实现优雅的服务降级,提升用户体验。 70%的故障都是因为代码变更引起的,所以有时候回退代码并不算是什么坏事。 如果发生故障,就要让它们快速而独立的发生。一个团队无法控制他们服务的依赖项。 缓存、隔板、回路断路器和速率限定器这些架构模式有助于构建可靠的微服务。 微服务架构通过定义良好的边界让失效隔离成为可能,但每一个分布式系统都存在同样的问题——网络、硬件或应用程序层面都有可能出现故障。因为服务之间存在依赖关系,所以任何一个组件出现了问题都会影响到组件依赖者。为了最小化局部故障所带来的影响,我们需要构建具有容错能力的服务,可以优雅地应对某些类型的故障。 这篇文章基于RisingStack的Node.js咨询和开发经验,介绍构建高可用微服务系统的常用技术和架构模式。 如果你不熟悉这篇文章所介绍的模式,并不代表你现在所做的就是错的,毕竟构建一个可靠的系统需要付出额外的代价。 微服务架构的风险 微服务架构将业务逻辑分散到了各个微服务当中,微服务间...
- 下一篇
微服务MySQL分库分表数据到MongoDB同步方案[转]
需求背景 近年来,微服务概念持续火热,网络上针对微服务和单体架构的讨论也是越来越多,面对日益增长的业务需求是,很多公司做技术架构升级时优先选用微服务方式。我所在公司也是选的这个方向来升级技术架构,以支撑更大访问量和更方便的业务扩展。 发现问题 微服务拆分主要分两种方式:拆分业务系统不拆分数据库,拆分业务系统拆分库。如果数据规模小的话大可不必拆分数据库,因为拆分数据看必将面对多维度数据查询,跨进程之间的事务等问题。而我所在公司随着业务发展单数据库实例已经不能满足业务需要,所以选择了拆分业务系统同时拆分数据库的模式,所以也面临着以上的问题。本文主要介绍多维度数据实时查询解决方案。当前系统架构和存储结构如下: 解决思路 要对多数据库数据进行查询,首先就需要将数据库同步到一起以方便查询 为了满足大数据量数据需求,所以优先选择NOSQL数据库做同步库 NOSQL数据库基本无法进行关联查询,所以需要将关系数据进行拼接操作,转换成非关系型数据 业务多维度查询需要实时性,所以需要选择NOSQL中实时性相对比较好的数据库:MongoDB 根据以上思路,总结数据整合架构如下图所示: 解决方案 目前网上一些...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7设置SWAP分区,小内存服务器的救世主
- Hadoop3单机部署,实现最简伪集群
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题