企业官网建设流程全解析

外国工业设计网站,求建设网站微信群,如何网站全部结构,西宁做网站的公司力请君博d有时候我就在想#xff0c;咱们搞技术的#xff0c;特别是做后端和运维的兄弟#xff0c;最烦的是什么#xff1f; 不是代码写不出来#xff0c;是从头搭建一套高可用的分布式计算集群#xff0c;仅仅是为了跑一个只需要运行十分钟的数据分析脚本。你为了喝口醋#xf…有时候我就在想咱们搞技术的特别是做后端和运维的兄弟最烦的是什么不是代码写不出来是从头搭建一套高可用的分布式计算集群仅仅是为了跑一个只需要运行十分钟的数据分析脚本。你为了喝口醋特意包了顿饺子还得把厨房重新装修一遍这事儿放谁身上都得骂娘。前段时间公司有个业务需求临时要处理几百个G的日志文件做个简单的正则匹配和统计。你要是用单机跑吧Python那个GIL锁你也懂的跑完估计得等到下个季度你要是上Spark或者Hadoop吧光是配置环境、申请资源、调优参数半天就过去了。我就琢磨有没有一种办法能让我像写普通Python脚本一样简单但是一运行就能瞬间在云端唤醒几千个CPU核心帮我干活干完活这些核心就自动销毁不占地儿也不扣钱这就不得不提今天要聊的主角Pywren加上AWS Lambda。这玩意儿刚出来的时候我看Eric Jonas作者的演示下巴都快掉地上了。这哪是云计算啊这简直就是“影分身之术”。今天咱们就扒开揉碎了聊聊怎么用这套组合拳把你的笔记本电脑变成一台超级计算机。什么是Pywren为什么是它说白了Pywren就是个Python库。它的核心逻辑非常简单粗暴你把数据切成一块一块的然后Pywren帮你把你的Python函数和这些数据块通过AWS Lambda亚马逊的无服务器计算服务瞬间分发出去。想象一下你手里有一万张图片要缩放。传统做法写个循环一张张处理或者开个多线程池。Pywren的做法它把你的“缩放函数”序列化打包然后瞬间调用1000个AWS Lambda函数每个Lambda处理10张图。在这一瞬间你拥有了1000个CPU核心的算力。这就是Serverless的魅力。不用管服务器有没有宕机不用管内存够不够只要单个任务不超限更不用管操作系统是不是又该打补丁了。可能有人会说“哎呀现在不是有Ray有Dask吗”是有但Pywren的那种“无状态”、“极简主义”的哲学依然非常适合那种突发性、高并发、计算密集型的任务。而且它跟AWS的整合度真的是太丝滑了。准备工作和AWS IAM搏斗要玩转这个首先你得有个AWS账号。这个我就不教了信用卡准备好就行。最让人头疼的其实是权限配置。AWS的IAM身份与访问管理设计得是非常精妙但对于新手来说简直就是迷宫。你需要配置一个用户给它足够的权限去操作S3存储数据和Lambda执行代码。我在第一次搞的时候踩了不少坑报错报得我怀疑人生。这里给个经验之谈尽量遵循最小权限原则但在测试阶段为了不把自己气死先把S3 FullAccess和Lambda FullAccess给加上等跑通了再慢慢阉割权限。你需要在本地配置好~/.aws/credentials大概长这样[default] aws_access_key_id AKIAXXXXXXXXXXXXXXXX aws_secret_access_key YOUR_SECRET_KEY region us-east-1记得Region区域选离你数据近的。如果你的数据都在S3的us-east-1你非要把Lambda开在东京光是网络传输延迟和跨区域流量费就能让你老板找你谈话。然后是Pywren的配置文件。一般在~/.pywren_config。这文件里得告诉Pywren你的S3桶叫什么名字。Pywren工作的时候会把你的代码打包上传到S3Lambda启动时再去S3拉取代码和数据。S3在这里充当了一个“中转站”和“协调员”的角色。account:aws_access_key_id:YOUR_KEYaws_secret_access_key:YOUR_SECRETaws_region:us-east-1storage:bucket:my-pywren-bucketprefix:pywren.jobs这里的bucket一定要是你自己创建好的而且要在同一个Region。Hello World点火起飞环境弄好了咱们来写个最简单的。通常我们写Python的map是这样的defmy_function(x):returnx1data[1,2,3,4,5]resultslist(map(my_function,data))用Pywren怎么写几乎一模一样importpywrenimportnumpyasnpdefmy_function(x):returnx1# 模拟一个大一点的数据集datanp.arange(100)wrenexecpywren.default_executor()futureswrenexec.map(my_function,data)# 获取结果resultspywren.get_all_results(futures)print(results)看到没就改了那么两行。但是当你运行这段代码的时候后台发生的事情堪比好莱坞大片。序列化Pywren利用cloudpickle把你本地定义的my_function连同它依赖的上下文全部打包成一个二进制对象。上传这个对象被扔到了S3上。触发Pywren调用AWS Lambda API告诉AWS“嘿给我启动100个Lambda容器”拉取与执行那100个Lambda容器在AWS的数据中心里几乎同时启动它们去S3下载刚才那个打包好的函数对象反序列化然后分别拿到属于自己的那一份数据比如第一个拿到0第二个拿到1…。回传计算完成后Lambda把结果再写回S3。汇聚你本地的脚本轮询S3发现结果都回来了把它组装成一个列表打印出来。当你看着进度条“刷”一下走完的时候那种掌控雷电的感觉真的爽。进阶依赖地狱与Runtime好Hello World跑通了你肯定想搞点大的。比如用pandas处理数据或者用cv2处理图像。这时候问题来了。AWS Lambda的底层环境是Amazon Linux里面只有标准的Python库。你本地装了pandasLambda上可没有。你代码一跑立马报错ModuleNotFoundError: No module named pandas。这时候就得聊聊Pywren的Runtime机制了。Pywren允许你打包一个Conda环境或者Virtualenv环境上传到S3然后告诉Lambda“启动的时候先别急着干活先把这个环境给我解压了把PYTHONPATH指过去。”但是这招有个致命弱点慢。Lambda也是有冷启动时间的。如果你的环境包有500MB光下载解压就得几十秒。Lambda是按毫秒计费的这都是钱啊而且Lambda有各种限制比如部署包大小限制虽然现在放宽了以前是50MB临时磁盘空间限制/tmp 只有512MB到10GB不等看配置。比较优雅的做法是使用AWS Lambda Layers或者构建一个包含所有依赖的Docker镜像如果你用的是支持Docker镜像的新版Pywren分支比如Lithops。对于老版本的Pywren我们通常会预先构建一个包含常用库numpy, scipy, pandas的Runtime包部署到AWS上。只要你的依赖搞定了剩下的就是纯粹的业务逻辑。我之前有个任务需要爬取几万个网页并提取正文。如果是单机跑光是等待HTTP响应就得急死人。哪怕用了asyncio带宽也是瓶颈。上了Pywren之后直接并发1000个Function。这就相当于你有1000个不同的IPLambda的IP池很大在同时抓取。当然这种做法要小心别把人家目标网站打挂了否则你这就是DDOS攻击搞不好要进局子的。一定要加随机延迟做个守法的好公民。真实场景分布式日志分析来个硬核点的实战案例。假设我们在S3上存了一堆Gzip压缩的Nginx日志按天分文件夹一年下来有好几个TB。老板突然脑子一热问“去年有多少来自IP 1.2.3.4的请求在周五晚上访问了/admin路径”这需求你要是用S3 Select可能也行但灵活性不够。你要是下载下来grep网卡都得烧了。用Pywren怎么搞首先S3上的文件列表列出来假设有10000个文件。importpywrenimportboto3importgzipdefprocess_log_file(key):s3boto3.client(s3)# 智能读取不下载整个文件到内存流式处理objs3.get_object(Bucketmy-logs,Keykey)count0withgzip.open(obj[Body],rt)asf:forlineinf:if1.2.3.4inlineand/admininline:# 这里还可以加更复杂的逻辑比如时间解析count1returncount# 获取所有文件Keys3_resourceboto3.resource(s3)keys[o.keyforoins3_resource.Bucket(my-logs).objects.all()]wrenexecpywren.default_executor()# 将任务分发出去futureswrenexec.map(process_log_file,keys)resultspywren.get_all_results(futures)total_hitssum(results)print(f总点击量:{total_hits})这段代码看似平平无奇但它能在几分钟内跑完单机几天的工作量。这里有几个技术细节要敲黑板数据本地性Data Locality虽然Lambda和S3都在AWS内部速度很快但毕竟还是过网络的。尽量在Lambda内部进行数据过滤只返回你需要的结果比如一个数字或者一小段文本千万别在Lambda里把数据读出来啥也不干直接返回那样你会把回传S3的带宽撑爆而且序列化结果也要花时间的。内存管理Lambda是按内存分配CPU算力的。你选128MB内存它就给你分配很小比例的CPU你选1792MB相当于1个完整vCPU处理速度会快很多。对于计算密集型任务别省这点内存钱把内存拉高运行时间短了总费用说不定反而更低。超时时间AWS Lambda目前最大运行时间是15分钟。如果你的单个文件处理时间超过15分钟任务就会被强杀你就拿不到结果了。所以任务切分粒度很重要。如果文件太大得想办法分块读。那些年踩过的坑血泪史吹了半天好接下来说说坑。这部分才是最值钱的省得你们重蹈覆辙。1. 钱包的尖叫Serverless说是按量付费便宜。那是针对低频、波动大的业务。如果你拿它跑7*24小时的高负载计算那账单能让你原地破产。一定要算清楚Lambda调用次数费用 Lambda运行时间GB-秒费用 S3请求次数费用 S3传输流量费用。特别是S3请求费Pywren工作时会产生大量的GET/PUT请求。假如代码写了个死循环不断轮询S3状态一晚上跑了几千万次请求第二天一看账单你会滴血。2. 冷启动的痛虽然Pywren尽量复用Lambda容器但如果你并发量突然从0飙到3000AWS需要现给你起容器。这时候前几秒的性能会很差甚至会有超时的。如果在意延迟需要预热但在批处理场景下这倒不是大问题。3. 调试极其困难当代码在本地跑得欢一上云就崩你怎么排查你看不到Lambda的控制台输出只能去AWS CloudWatch看日志。几千个流的日志混在一起查错简直是大海捞针。Pywren虽然提供了一些工具获取远端异常但如果是因为内存溢出OOM直接被AWS杀掉的进程Pywren可能只会在客户端报个“Timeout”或者连接中断你根本不知道是代码写错了还是内存不够了。技巧在代码里多写print然后在CloudWatch里用Insights语法查询。或者先用小数据集、单并发在本地模拟模式下跑通逻辑。4. Pickle不是万能的Python的序列化机制Pickle很强但不是啥都能打包。比如打开的文件句柄、数据库连接对象、C语言扩展的某些指针是没法序列化传到Lambda上去的。你的代码必须是“无状态”的。所有的连接必须在函数内部Lambda端创建不能在本地创建好传过去。架构思考它不是万能药用了一段时间Pywren后我对其有了更深的理解。它不是用来替代Spark或Flink的。如果你的数据之间有复杂的依赖关系比如Shuffle操作Reducer需要等待所有Mapper结束Pywren处理起来会很吃力。因为它没有像Spark那样完善的DAG调度器和中间数据交换机制Shuffle主要靠写回S3效率不如内存交换。Pywren最适合的是**“易并行Embarrassingly Parallel”**的任务。就是那种大家各干各的谁也不碍着谁最后汇总一下就行。比如蒙特卡洛模拟、超参数搜索、大规模ETL清洗、音视频转码。对于这种任务Pywren Lambda 简直是降维打击。不需要维护Kubernetes集群不需要写Dockerfile脚本一扔算力自来。总结在这个云原生的时代运维和开发的边界越来越模糊。以前我们得守着服务器盯着负载均衡现在我们更多的是在调度资源编写流程。Pywren这种工具的出现其实是在告诉我们算力已经变成了一种像水电一样的基础设施。你不需要拥有一台发电机你只需要学会怎么插插座。如果你还没试过这种开发模式强烈建议你今晚就去申请个AWS账号新用户还有免费额度把手头那些跑得慢的脚本改造成Serverless版本。那种瞬间调动成千上万个核心为你工作的快感绝对比打游戏通关还要爽。当然爽完记得去AWS后台把S3里的临时文件清一下不然下个月账单出来别怪我没提醒你。好了今天就聊到这。关于Pywren或者Serverless还有什么想问的或者是你在实战中遇到过什么奇葩的坑欢迎在评论区留言咱们一起探讨探讨。毕竟技术这条路一个人走太孤单一群人走才有意思。记得关注我下期咱们聊聊怎么用Terraform把这套架构代码化彻底解放双手。公众号运维躬行录个人博客躬行笔记