社区
AWS
帖子详情
基于附近的人 社交app的AWS架构图(含广告推送和客户行为分析)
tigerwangcf
2017-07-14 09:33:53
哪位大神可以帮小弟做一个架构图:基于附近的人定位的 社交app的AWS架构图(含广告推送和客户行为分析),需要跨region。
...全文
2268
2
打赏
收藏
基于附近的人 社交app的AWS架构图(含广告推送和客户行为分析)
哪位大神可以帮小弟做一个架构图:基于附近的人定位的 社交app的AWS架构图(含广告推送和客户行为分析),需要跨region。
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
2 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
基于微软Azure、.NET Core和Docker的博客系统.zip
首先简要介绍一下目前的站点功能吧。右图就是本站的主页效果,我做得很简洁,没有用太多花哨的图片,也没有用走马灯。明眼人一看就知道这是基于ASP.NET MVC而开发的Web应用程序,使用了Bootstrap。不错,基本答对!需要强调的是,这个博客站点以及后端的RESTful服务,全部都是基于ASP.NET Core完成的,.NET Core运行时版本为1.1.0,运行在Docker容器中。哎,说着说着又到技术上了,功能还没介绍完呢。说到功能,目前功能很简单:主页列出了我自己原创或者翻译的所有文章,读者可以注册用户帐号,注册用户可以发表评论,也可以在用户管理页面中更改自己的昵称。好了,目前功能就这么多,别看功能少,我可是前前后后陆陆续续花了2个月的时间,才做到目前这个样子。当然,我会继续更新这个站点,让它的功能变得更加完善。提到ASP.NET Core,有没有吊起你的技术胃口呢?不用着急,接下来我就介绍一下整个站点中各部分的技术选型,看完后,或许你会知道为什么我花了2个月的业余时间,才整出来这么个简单的玩意儿。站点技术介绍整体架构整个网站所采用的所有基础设施全部运行在微软云(Windows Azure)中,使用了部分托管资源,以及一些非托管的Azure VM。大致情况如下:图片存储服务:由Azure Blob Storage Service托管数据库系统:由Azure SQL Database托管(未启用Geo-Replication,因为没钱)邮件服务:由Azure SendGrid Account托管(Pricing Tier为F1,每月可以免费发送25000封邮件)应用服务器:基于Azure构建的Ubuntu 16.04.1 LTS虚拟机,运行了两个Docker容器:blog-web和blog-service,分别托管前端Web站点和后端RESTful服务。后端RESTful API服务没有做任何认证和授权,Web站点通过内部子网访问RESTful API服务,Docker容器运行在非托管环境中持续集成系统:Jenkins,基于Azure构建的Windows Server 2012 R2一台(Master),和一台Ubuntu 16.04.1 LTS(Slave)。站点的前端和后端都在后者(Ubuntu)中完成编译、打包以及Docker镜像的发布,实现了一步到位的部署方式代码库:Github有人会问:为什么使用了非托管的Azure VM环境运行应用系统?我也考虑过这个问题,理论上讲,基于云的系统架构最好选用托管的PaaS服务,这样不仅可以得到纯天然的高可用性(包括灾备,比如
AWS
的跨AZ部署,某些服务跨区域的可用性,以及负载均衡),而且还可以得到专业的技术支持。只有当存在老系统向云迁移的需求,并需要迎合老系统的特定运行环境要求时,才考虑使用IaaS服务。虽然虚拟机等这些资源是由Azure负责创建并运行的,在这一层面Azure可以保证虚机的可用性,但虚机内部运行的任何程序的状态,以及所使用的数据,Azure等云服务是无从得知的,对这部分东西的监控也会变得很麻烦。出于安全考虑,通常云服务供应商是不会,也不应该获得类似虚机内部的
客户
程序的运行数据的,使用虚拟机服务所产生的程序运行风险,
客户
需要自己承担。这也就是著名的责任共担原则。看起来用虚拟机运行应用不是太靠谱嘛,然而我却选择这么使用了。有几个原因:为何不使用Azure Web
App
?一方面Jenkins做自动化部署,直接把编译好的应用
推送
到Azure Web
App
中好像不是太顺手,要写一些PowerShell的代码,可是我的编译系统是Linux,不过现在已经有Linux版的PowerShell了,而且Azure SDK Command Line Interface也有Linux版,所以这个理由有点牵强,更合理的解释是:劳资不会!另一方面,我没有在服务端做认证和授权,仅通过子网向外界提供服务,所以我希望我的Web
App
也运行在子网内部,然后向外暴露80端口供外界访问。这样一来,Azure Web
App
又如何部署到我自己的子网内?这是一个技术问题,我相信一定有解决方案,但是我也没太多时间和精力去细究如何实现,自己的第一反应也无非是将前后端全部部署在Azure Web
App
中,然后打开后端的认证机制。但这样做又要花一些额外的工夫。好吧,还是这个理由:劳资不会为何不使用Azure Container Service?Azure Container Service会在你指定的Resource Group(资源组)中创建一整套网络部署,包括好几台虚拟机、公网IP、两个负载均衡器等等,我想你一定知道我为什么没有选择Azure Container Service了,原因就是:劳资没钱理由够充分吧?微软Windows Azure提供的这些服务都很赞,我没选不是说它们不好用,而是出于自己的实际情况考虑:某些服务的学习成本经济成本暂时没必要做到99.99999%的高可用率即使应用挂了,恢复的成本很小:数据完全不需要恢复,托管的SQL Database、Blob Storage会保证我的数据不丢失,应用程序恢复也很简单:重新运行Docker容器就完事儿OK,从整体架构上看,我的选择即是如此而已,这样的选择当然不一定完全正确,但我觉得至少合适,仅供参考。下面附上本站点的整体
架构图
。作几点注解:三台VM位于同一个Virtual Network的subnet中,每台VM的虚拟网卡上都套有独立的Network Security Group(NSG),在NSG上设置了Inbound/Outbound Endpoints,严格限制了端口访问的IP地址。三台VM之间使用subnet IP地址访问Windows Server 2012 VM宿主了Jenkins Master,以及Seq日志服务。它向公网暴露8080端口和5342端口,分别用于访问Jenkins服务和Seq管理界面第一台Ubuntu VM运行了Jenkins Slave,它不向公网暴露任何端口,仅向Jenkins Master机器暴露22端口,用于Jenkins Slave Agent的执行调度第二台Ubuntu VM运行了博客系统的两个Docker容器:前端应用程序blog-web和后端RESTful API服务程序blog-service。web通过子网IP地址访问service,VM仅向公网暴露80端口,后台service无法从公网访问两个Docker容器所运行的应用(blog-web和blog-service)都可以访问托管的Azure SQL database、Azure Storage blob和SendGrid Account服务整个部署的拓扑结构有可能不太合理,比如没有做负载均衡,没有使用托管的应用宿主服务(比如Azure Web
App
、Container Service等),没有使用Scaleset。因为目前没必要而且没钱更多说明,详见作者的博客:http://daxnet.me/blogposts/post/221 标签:daxnet
TF11-jenkins-fargate:用于创建Fargate容器的JenkinsTF管道
项目:TF11-詹金斯-法盖特 目的:该项目使用Terraform&Jenkins创建负载均衡的Fargate基础架构。 一个简单的应用程序在
AWS
云平台上的三个相互连接的Docker容器中运行。 作者:弗兰克·埃夫林·博奇 图书馆: : 该项目是jenkins管道的一部分,该管道监视我其他git repo(lab051-build-docker-image)中的更改。 当在存储库中检测到更改时,将执行以下操作。 [1] Jenkins从github仓库中克隆了“ DOCKER-profile-
app
-mongodb”,并构建了一个新的docker镜像。 [2] Jenkins将新映像
推送
到Docker Hub。 [3]詹金斯(Jenkins)克隆了这个git repo并指示Terraform构建
AWS
云基础架构。 [4] Terraform从Docker Hub中提取d
AWS
云服务快速入门实战
本课程将以一个
AWS
云服务实际使用案例为基础,讲解常用
AWS
服务使用。基于实战直接快速深入理解
AWS
相关服务,使得学员在最短的时间内获得最大的知识经验积累。学完本套课程您将具有一定的云设计和使用经验。本课程将涉及到:不同
AWS
网络架构模型设计掌握网络相关使用,包括VPC/Subnet/RouteTable/Endpoint/NAT Gateway等相关知识掌握EC2相关使用,包括EC2/AMI/Snapshot 等掌握IAM/KMS/S3相关使用掌握CloudWatch/CloudTrail相关使用掌握Lambda相关使用掌握CloudFormation相关使用掌握Route53相关使用掌握
AWS
CLI相关使用掌握
AWS
Price计算使用
企业级的消息
推送
架构设计,硬核!
构建企业级统一基础
推送
服务,支持通过多渠道
推送
,能够统一集成的电子邮件、短信、聊天、钉钉、企业微信和其他公共
社交
应用:聊天 - 微信Wechat/QQ站内
推送
通知(移动设备和Web浏览器)站外
推送
通知(移动设备,
APP
没有开启)短信(如登录密码、营销活动)电子邮件钉钉企业微信企业级统一基础
推送
服务,是一个通用特性,适用于所有现代分布式应用,无论采用何种编程语言和技术。
推送
能力的演进第一阶段(模块化...
架构设计内容分享(四十九):消息
推送
架构设计
例如,在B站视频网站平台上,评论服务作为一项原子服务,在B站的视频、文章、社区都需要,那么为了提高复用性,评论服务就可以独立为原子服务,不能与特定需求紧密耦合。类似的,文件存储、数据存储、
推送
服务、身份验证服务等功能,都会沉淀为原子服务,业务开发人员,在原子服务基础上,进行编排、配置、组合,可以快速构建业务应用。它能提供良好的性能和低延迟,适应大量的通知,因为它内部处理大量的写操作,并与其他数据库节点同步,保持高可用性和可靠性的冗余数据/消息。:专门用于发送批量通知的
客户
端,负责向用户批量
推送
通知。
AWS
409
社区成员
536
社区内容
发帖
与我相关
我的任务
AWS
AWS
复制链接
扫一扫
分享
社区描述
AWS
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章