整理了十个Python自动化操作，拿走就用！
01
OS模块相关
一、遍历文件夹
批量操作的前提就是对文件夹进行遍历，使用os模块可以轻松的遍历文件夹，os.walk 遍历后产生三个参数：
“
当前文件夹路径 包含文件夹名称[列表形式] 包含文件名称[列表形式] ”
代码如下，大家可以根据自己的路径进行修改
import os
for dirpath, dirnames, filenames in os.walk(r'C:\Program Files (x86)'):
print(f'打开文件夹{dirpath}') # 当前文件夹路径 if dirnames:
print(dirnames) # 包含文件夹名称[列表形式] if filenames:
print(filenames) # 包含文件名称[列表形式] print('-' * 10)
当手上的需求明确有获取给定路径各级文件夹下所有符合条件的文件，并进行相应的批处理操作时，即可使用 os.walk
二、 目标路径是否是文件
有时我们需要判断一个目录下是否存在文件也可以使用os模块。
给定一个目标路径 path ，通过一行代码就能够判断这是文件还是文件夹路径
import os path = 'xxx'print(os.path.isfile(path))
三、获取路径中的文件名
os.path.basename 可以直接从绝对路径中获取最后的文件名，当然如果用传统的字符串切割方式也可以，即 path.split('\')[-1]
import os path = 'xxx'print(os.path.basename)
四、创建文件夹
创建文件夹的代码非常常用，因为往往生成的新文件都希望有个新的文件夹存储，代码如下：
import os dirpath = 'xxx'os.mkdir(dirpath)
但是，如果希望创建的文件夹已经存在，再运行 os.mkdir() 则会报错而终止代码。为了避免这一情况的发生，可以在创建文件夹之前先判断文件夹是否存在。
用到的代码是 os.path.exists，只有当路径不存在（即 os.path.exists 返回的结果是 False 时），才会创建：
import os
dirpath = 'xxx'if not os.path.exists(dirpath):
os.mkdir(dirpath)
五、获取桌面路径
获取桌面路径也是非常常用的操作，可以使用os.path.join(os.path.expanduser("~"), 'Desktop') 获取桌面的绝对路径。
这样做的好处是可以把数据放在桌面上，在不同的电脑上都能调用代码对数据进行处理。如果是在一条电脑上把桌面路径固定在字符串中，则换一台电脑就必须修改桌面路径。代码如下：
import os
desktop_path = os.path.join(os.path.expanduser("~"), 'Desktop')
print(desktop_path)
当然把上面的代码包装成一个函数 GetDesktopPath() 需要时调用它会更加方便
import osdef GetDesktopPath(): return os.path.join(os.path.expanduser("~"), 'Desktop')
六、重命名文件/文件夹
需要用到 os.rename() 方法，下面的代码示例中分别演示如何重命名文件和文件夹
import os
os.rename('practice.txt', 'practice_rename.txt') # 重命名文件os.rename('文件夹1', '文件夹2') # 重命名文件夹
七、批处理文件 – 1
除了前面的 os.walk 之外，有其他的 os 模块下方法可完成获取指定路径的全部或符合条件的文件（非遍历各级文件夹的需求），还可以使用下面两个代码第一种用到的方法是os.scandir()，使用如下：
import os
path = 'xxx'for file in os.scandir(path):
print(file.name, file.path)
八、批处理文件 – 2
上面代码最后输出的是 给定路径下各内容的名字、绝对路径第二种方法使用 os.listdir()，它比 os.scandir() 简单一些，可直接调用输出名称而非路径：
import os
path = 'xxx'for file in os.listdir(path):
print(file)
02
shutil模块相关
九、移动文件/文件夹
shutil也是经常出现在办公自动化场景中的模块，我常用的就是移动文件/文件夹。
需要用到shutil.move 方法，下面的代码示例中分别演示如何移动文件和文件夹：
import shutil shutil.move(r'.practice.txt', r'.文件夹1/') shutil.move(r'.practice.txt', r'.文件夹1/new.txt')
注意到上面后两行代码的区别吗？前一行是将目标文件移动到目标文件夹里，而后一行，在将目标文件移动到目标文件夹里的同时，能够对其进行重命名
也就是说，如果我们需要移动某个或某些文件到新的文件夹，并且需重命名文件，则我们并不需要用 os.rename 先命名文件再用 shutil.move 将其移动的指定文件夹，而是可以用 shutil.move 一步到位
03
glob模块相关
十、批处理文件 – 3
最后要介绍的是glob模块，也是办公自动化必须要掌握的一个模块，同样可以用于批处理文件。
glob 最重要的功能就是搜索获取同一级或者各子级下符合条件的文件（绝对路径），非常适合写批处理的代码。
有时候我们需要对大量文件进行相同操作，在写完针对一份文件的操作后，只需要加上几行代码，就可以完成批处理全部文件的工作。大致代码框架如下：
import glob
for file in glob.glob('**/*', recursive=True):
print(file)
glob.glob() 是一个非常重要的方法，能够获取给定路径下文件的绝对路径，并且接受「通配符」搜索，大大拓宽了灵活程度，* 表示任意字符长度，**/* 的使用表示用通配符指代给定路径下的任何一层，recursive 参数允许遍历搜索。
— EOF —
转自：https://mp.weixin.qq.com/s/SQVhU7i7CUvP6iCvILjmcQ
Python 里最强的Web框架，早就不是Django和Flask了
来自：掘金，作者：ConnorZhang 链接：https://juejin.cn/post/6944598601674784775
如果说要用 Python 进行 web 开发，我想你一定会告诉我 使用 Flask 或者 Django 再或者 tornado， 用来用去无非就这三种框架。可能逛 github 多的朋友还会说一个 fastapi。但是，皇上，时代变了，大清… 亡了！！！
速度为先
当下，python都已经更新到了 Python3.9.3 了，如果你还没有使用过 asyncio、和 Python3.5 新增的 async/await 语法，那说明你可能真的是桃花源人，问今是何世，不知有汉，无论魏晋了
在当下，基于 async/await 语法的异步 Web 框架也有很多，在 github 上找一找比比皆是是，那究竟应该选哪一款呢？在 github 上有一个专门测试各种语言各种 Web 框架速度的项目，我们来看一看简单的数这是所有的 Python Web 框架速度测试，有人可能会问为什么不是从 1 开始排序的，因为这个项目的测试还包含 golang、java、php 等众多语言的 Web 框架，共有 226 款。这里我们只用 Python 来做对比。
可以明显的看到，flask、django、tornado 等老牌的 Python Web 框架已经快要垫底了。
wow， 这个速度绝了。可能你们还在怀疑这个速度如何测试的，给你们看一下测试源码：
# Disable all logging featuresimport logging
logging.disable()
from flask import Flaskfrom meinheld import patch
patch.patch_all()
app = Flask(__name__)
@app.route("/")def index(): return ""
@app.route("/user/<int:id>", methods=["GET"])def user_info(id): return str(id)
@app.route("/user", methods=["POST"])def user(): return ""复制代码from django.http import HttpResponsefrom django.views.decorators.csrf import csrf_exempt
def index(request): return HttpResponse(status=200)
def get_user(request, id): return HttpResponse(id)
@csrf_exemptdef create_user(request): return HttpResponse(status=200)复制代码# Disable all logging featuresimport logging
logging.disable()
import tornado.httpserverimport tornado.ioloopimport tornado.web
class MainHandler(tornado.web.RequestHandler): def get(self): pass
class UserHandler(tornado.web.RequestHandler): def post(self): pass
class UserInfoHandler(tornado.web.RequestHandler): def get(self, id): self.write(id)
app = tornado.web.Application( handlers=[ (r"/", MainHandler), (r"/user", UserHandler), (r"/user/(d+)", UserInfoHandler), ])复制代码# Disable all logging featuresimport logging
logging.disable()
import multiprocessing
from sanic import Sanicfrom sanic.response import text
app = Sanic("benchmark")
@app.route("/")async def index(request): return text("")
@app.route("/user/<id:int>", methods=["GET"])async def user_info(request, id): return text(str(id))
@app.route("/user", methods=["POST"])async def user(request): return text("")
if __name__ == "__main__": workers = multiprocessing.cpu_count() app.run(host="0.0.0.0", port=3000, workers=workers, debug=False, access_log=False)复制代码就是简单的不做任何操作，只返回响应，虽然这样测试没有任何实际意义，在正常的生产环境中不可能什么都不做，但是如果所有的框架都如此测试，也算是从一定程度上在同一起跑线上了吧。
OK，就这么多，说到这里你也应该知道我想要说的这个异步框架是谁了，没错，我们今天的主角就是 Sanic。
为什么要用异步 Web 框架？
这可能是众多小伙伴最先想到的问题了吧？我用 Django、Flask 用的好好的，能够完成正常的任务，为什么还要用异步 Web 框架呢？
说到这里，首先我要反问你你一个问题，你认为在 Web 开发过程中我们最大的敌人是谁？思考 5 秒钟，然后看看我的回答：
在 Web 开发的过程中，我们最大的敌人不是用户，而是阻塞！
是的，而异步可以有效的解决 网络 I/O 阻塞，文件 I/O 阻塞。具体的阻塞相关的文章推荐查看深入理解 Python 异步编程。由于异步可以提升效率，所以对于 Python 来说，异步是最好的提升性能的方式之一。这也是为什么要选择 异步 Web 框架的原因。
生态环境
可能有的小伙伴还是会说，你为什么不推荐 falcon 而是推荐 Sanic ？明明它的速度非常快，要比 Sanic 快了那么多，那您看一下下面的代码：
from wsgiref.simple_server import make_serverimport falcon
class ThingsResource: def on_get(self, req, resp): """Handles GET requests""" resp.status = falcon.HTTP_200 # This is the default status resp.content_type = falcon.MEDIA_TEXT # Default is JSON, so override resp.text = ('nTwo things awe me most, the starry sky ' 'above me and the moral law within me.n' 'n' ' ~ Immanuel Kantnn')
app = falcon.App()
things = ThingsResource()
app.add_route('/things', things)
if __name__ == '__main__': with make_server('', 8000, app) as httpd: print('Serving on port 8000...')
httpd.serve_forever()一个状态码都要自己定义和填写的框架，我想它的速度快是值得肯定的，但是对于开发者来说，又有多少的实用价值呢？所以我们选择框架并不是要选最快的，而是要又快又好用的。
而大多数框架并不具备这样的生态环境，这应该也是为什么大多数 Python 的 Web 开发者愿意选择 Django 、 Flask 、 tornado 的原因。就是因为它们的生态相对于其他框架要丰富太多太多。
可是，如今不一样了。Sanic 框架， 从 2016 年 5 月开始 发布了第一版异步 Web 框架雏形，至今已经走过了 5 个年头，这 5 年，经过不断地技术积累，Sanic 已经由一个步履蹒跚的小框架变成了一个健步如飞的稳重框架。
在 awesome-sanic 项目中，记录了大量的第三方库，你可以找到任何常用的工具：从 API 到 Authentication，从 Development 到 Frontend，从 Monitoring 到 ORM，从 Caching 到 Queue… 只有你想不到的，没有它没有的第三方拓展。
生产环境
以前我在国内的社区中看到过一些小伙伴在问 2020 年了，Sanic 可以用于生产环境了吗？
答案是肯定的，笔者以亲身经历来作证，从19年底，我们就已经将 Sanic 用于生产环境了。彼时的 Sanic 还是 19.9，笔者经历了 Sanic 19.9 — 21.3 所有的 Sanic 的版本，眼看着 Sanic 的生态环境变得越来越棒。
还有一个问题可能你们不知道，Sanic 在创建之初目标就是创建一个可以用于生产环境的 Web 框架。可能有些框架会明确的说明框架中自带的 Run 方法仅用于测试环境，不要使用自带的 Run 方法用于部署环境。但是 Sanic 所创建的不止是一个用于测试环境的应用，更是可以直接用在生产环境中的应用。省去了使用 unicorn 等部署的烦恼！
文档完善
想必大多数 Python 的 Web 开发者 学的第一个框架就是 Flask 或者 Django 吧，尤其是 Django 的文档，我想大多数小伙伴看了都会心塞。因为旧的版本有中文，但是新的版本，尤其是新特性，完全没有任何中文文档了！！！！这对于关注 Django 发展但英文又不是强项的同学来说，简直苦不堪言。
但 Sanic 拥有完善的 中文用户指南 和 API 文档，这些都是由贡献者自主发起的，官方承认的文档，由翻译者进行翻译贡献，由 Sanic 官方团队进行发布。或许有的小伙伴会说 Flask 也有完善的中文文档，但是那是在不同的站点上的，Sanic 的所有文档都有 Sanic 官方进行发布支持。且目前 Sanic 还在持续支持 韩语、葡萄牙语等更多的语种。
社区指导
和其他框架不同，您或许能够在百度上找到论坛、频道等，但这些都是经过本地汉化的，运营者往往并不是官方，且其中夹杂了很多广告。很显然，如果是官方运营的不可能允许这种情况出现。
Sanic 不同于其他的社区，所有的论坛、频道完全由官方运营，在这里，你可以向核心开发者提问问题，Sanic 的官方发布经理也非常乐意回答各种问题。你也可以和志同道合的使用者分享自己的使用经验。这是一个完全开放的环境….
Sanic 目前常用的有 论坛、Discord、github issues、twitter、Stackoverflow
大家可以在以上的方式中关注 Sanic 的发展以及寻求社区帮助。
你还在等什么？还不赶紧去试一下？最后，以 Sanic 的愿景结尾：Build Faster， Run Faster !
— EOF —
转自：
写好 Python 代码的几条重要技巧
作者：韦世东
来源：NightTeam
程序设计的好与坏，早在我们青葱岁月时就接触过了，只是那是并不知道这竟如此重要。能够立即改善程序设计、写出“好”代码的知识有以下几点：
·面向对象五个基本原则；·常见的三种架构；·绘图；·起一个好名字；·优化嵌套的 if else 代码；
当然，其他技术知识的丰富程度也决定了程序设计的好坏。例如通过引入消息队列解决双端性能差异问题、通过增加缓存层提高查询效率等。下面我们一起来看看，上面列出的知识点包含哪些内容，这些内容对代码和程序设计的改善有何帮助。
面向对象五个基本原则
本书作者是 2010 级学生，面向对象是作者青葱时期发展火热的编程范式。它的五个基本原则是：
·单一职责原则；·开放封闭原则；·依赖倒置原则；·接口隔离原则；·合成复用原则；
下面我们将通过对比和场景假设的方式了解五个基本原则对代码质量的影响。
立竿见影的单一职责原则
没错，立竿见影、效果卓越。对于我们这些自学编程无师自通的人来说，能把功能实现就可以了，根本没有时间考虑代码优化和维护成本问题。时光流逝，竟在接触编程很长一段时间后才发现它竟如此重要。
俗话说只要代码写的够烂，提升就足够明显。以一个从文件内容中匹配关键数据并根据匹配结果发出网络请求的案例，看看大部分程序员的写法：
import reimport requestsFILE = "./information.fet"def extract(file):fil = open(file, "r")content = fil.read()fil.close()find_object = re.search(r"url=d+", content)find = find_object.group(1)text = requests.get(find)return textif __name__ == "__main__":text = extract(FILE)print(text)
需求已经实现，这点毋庸置疑，但是问题来了：
·如果读取文件的时候发生异常了怎么办？·如果数据源发生变化该如何处理？·如果网络请求返回的数据不符合最终要求怎么办？
如果你心里的第一个反应是改代码，那你就要注意了。完成一件事中间的某个环节发生变化，改代码是在所难免的，但是如果按照上面这种写法，不仅代码越改越乱，连逻辑也会越来越乱。单一职责原则表达的是让一个函数尽量只做一件事，不要将多件事混杂在一个函数中。
上面的代码如果重新设计，我认为至少应该是这样的：
def get_source():"""获取数据源"""returndef extract_(val):"""匹配关键数据"""returndef fetch(val):"""发出网络请求"""returndef trim(val):"""修剪数据"""returndef extract(file):"""提取目标数据"""source = get_source()content = extract_(source)text = trim(fetch(content))return textif __name__ == "__main__":text = extract(FILE)print(text)
把原来放在一个函数中实现的多个步骤拆分成为多个更小的函数，每个函数只做一件事。当数据源发生变化时，只需要改动 get_source 相关的代码即可；如果网络请求返回的数据不符合最终要求，我们可以在 trim 函数中对它进行修剪。这样一来，代码应对变化的能力提高了许多，整个流程也变得更清晰易懂。改动前后的变化如下图所示：
单一职责原则的核心是解耦和增强内聚力，如果一个函数承担的职责过多，等于把这些职责耦合在一起，这种耦合会导致脆弱的设计。当发生变化时，原本的设计会遭受到意想不到的破坏。单一职责原则实际上是把一件事拆分成多个步骤，代码修改造成的影响范围很小。
让代码稳定性飞升的开放封闭原则和依赖倒置原则
开放封闭原则中的开放指的是对扩展开放，封闭指的是对修改封闭。需求总是变化的，业务方这个月让你把数据存储到 MySQL 数据库中，下个月就有可能让你导出到 Excel 表格里，这时候你就得改代码了。这个场景和上面的单一职责原则很相似，同样面临代码改动，单一职责原则示例主要表达的是通过解耦降低改动的影响，这里主要表达的是通过对扩展开放、对修改封闭提高程序应对变化的能力和提高程序稳定性。
稳定这个词如何理解呢？
较少的改动或者不改动即视为稳定，稳定意味着调用这个对象的其它代码拿到的结果是可以确定的，整体是稳定的。
按照一般程序员的写法，数据存储的代码大概是这样的：
class MySQLSave:def __init__(self):passdef insert(self):passdef update(self):passclass Business:def __init__(self):passdef save(self):saver = MySQLSave()saver.insert()
功能是能够实现的，这点毋庸置疑。来看看它如何应对变化，如果要更换存储，那么就意味着需要改代码。按照上面的代码示例，有两个选择：
·重新写一个存储到 ExcelSave 的类；·对 MySQLSave 类进行改动；
上面的两种选择，无论怎么选都会改动 2 个类。因为不仅存储的类需要改动，调用处的代码也需要更改。这样一来，它们整体都是不稳定的。如果换一种实现方式，根据依赖倒置的设计指导可以轻松应对这个问题。边看代码边理解：
import abcclass Save(metaclass=abc.ABCMeta):@abc.abstractmethoddef insert(self):pass@abc.abstractmethoddef update(self):passclass MySQLSave(Save):def __init__(self):self.classify = "mysql"passdef insert(self):passdef update(self):passclass Excel(Save):def __init__(self):self.classify = "excel"def insert(self):passdef update(self):passclass Business:def __init__(self, saver):self.saver = saverdef insert(self):self.saver.insert()def update(self):self.saver.update()if __name__ == "__main__":mysql_saver = MySQLSave()excel_saver = Excel()business = Business(mysql_saver)
这里通过内置的 abc 实现了一个抽象基类，这个基类的目的是强制子类实现要求的方法，以达到子类功能统一。子类功能统一后，无论调用它的哪个子类，都是稳定的，不会出现调用方还需要修改方法名或者修改传入参数的情况。
依赖倒置中的倒置，指的是依赖关系的倒置。之前的代码是调用方 Business 依赖对象 MySQLSave，一旦对象 MySQLSave 需要被替换， Business 就需要改动。依赖倒置中的依赖指的是对象的依赖关系，之前依赖的是实体，如果改为后面这种依赖抽象的方式，情况就会扭转过来：
实体 Business 依赖抽象有一个好处：抽象稳定。相对于多变的实体来说，抽象更稳定。代码改动前后的依赖关系发生了重大变化，之前调用方 Business 直接依赖于实体 MySQLSave，通过依赖倒置改造后 Busines 和 ExcelSave、 MySQLSave 全都依赖抽象。
这样做的好处是如果需要更换存储，只需要创建一个新的存储实体，然后调用 Business 时传递进去即可，这样可以不用改动 Business 的代码，符合面向修改封闭、面向扩展开放的开放封闭原则；
依赖倒置的具体实现方式使用了一种叫做依赖注入的手段，实际上单纯使用依赖注入、不使用依赖倒置也可以满足开闭原则要求，感兴趣的读者不妨试一试。
挑肥拣瘦的接口隔离原则
接口隔离原则中的接口指的是 Interface，而不是 Web 应用里面的 Restful 接口，但是在实际应用中可以将其抽象理解为相同的对象。接口隔离原则在设计层面看，跟单一职责原则的目的是一致的。接口隔离原则的指导思想是：
·调用方不应该依赖它不需要的接口；·依赖关系应当建立在最小接口上；
这实际上是告诉我们要给接口减肥，过多功能的接口可以选用拆分的方式优化。举个例子，现在为图书馆设计一个图书的抽象类：
import abcclass Book(metaclass=abc.ABCMeta):@abc.abstractmethoddef buy(self):pass@abc.abstractmethoddef borrow(self):pass@abc.abstractmethoddef shelf_off(self):pass@abc.abstractmethoddef shelf_on(self):pass
图可以被购买、可以被借阅、可以下架、可以上架，这看起来并没有什么问题。但这样一来这个抽象只能提供给管理人员使用，用户操作时需要再设定一个新的抽象类，因为你不可能让用户可以操纵图书上下架。接口隔离原则推荐的做法是把图书的上下架和图书购买、借阅分成 2 个抽象类，管理端的图书类继承 2 个抽象类，用户端的图书类继承 1 个抽象类。这么看起来是有点绕，不要慌，我们看图理解：
这样是不是一下就看懂了。这个指导思想很重要，不仅能够指导我们设计抽象接口，也能够指导我们设计 Restful 接口，还能够帮助我们发现现有接口存在的问题，从而设计出更合理的程序。
轻装上阵的合成复用原则
合成复用原则的指导思想是：尽量使用对象组合，而不是继承来达到复用的目的。合成复用的作用是降低对象之间的依赖，因为继承是强依赖关系，无论子类使用到父类的哪几个属性，子类都需要完全拥有父类。合成采用另一种方式实现对象之间的关联，降低依赖关系。
为什么推荐优先使用合成复用，而后考虑继承呢？
因为继承的强依赖关系，一旦被依赖的对象（父类）发生改变，那么依赖者（子类）也需要改变，合成复用则可以避免这样的情况出现。要注意的是，推荐优先使用复用，但并不是拒绝使用继承，该用的地方还得用。我们以一段代码为例，说明合成复用和继承的差异：
import abcclass Car:def move(self):passdef engine(self):passclass KateCar(Car):def move(self):passdef engine(self):passclass FluentCar(Car):def move(self):passdef engine(self):pass
这里的 Car 作为父类，拥有 move 和 engine 2 个重要属性，这时候如果需要给汽车涂装颜色，那么就要新增一个 color 属性，3 个类都要增加。如果使用合成复用的方式，可以这么写：
class Color:passclass KateCar:color = Color()def move(self):passdef engine(self):passclass FluentCar:color = Color()def move(self):passdef engine(self):pass
类对象合成复用的具体操作是在类中实例化一个类对象，然后在需要的时候调用它。代码可能没有那么直观，我们看图：
这个例子主要用于说明继承和合成复用的具体实现方式和前后变化，对于 Car 的继承无需深究，因为如果你执着地讨论为什么右图中的 2 个 Car 不用继承，就会陷入牛角尖。
这里的合成复用选用的实现方式是在 2 个 Car 里面实例化另一个类 Color，其实也可以用依赖注入的手段在外部实例化 Color，然后把实例对象传递给 2 个 Car。
常见的三种架构
了解多种不同的架构可以使我们的知识面更宽广，面对一类问题的时候可以提出其它解决办法。同时，了解多种架构可以让我们在设计阶段做好规划，避免后续频繁的重构。常见的三种架构分别是：
·单体架构；·分布式架构；·微服务架构；
单体架构
单体架构是我们平时接触较多的架构，也是相对容易理解的架构。单体架构把所有功能都聚合在一个应用里，我们可以简单地将这种架构视作：
这种架构简单、容易部署和测试，大部分应用的初期都采用单体架构。单体架构也有几个明显缺点：
·复杂性高，所有功能糅合在一个应用里，模块多、容易出现边界模糊，而且随着时间的推移和业务的发展，项目越来越大、代码越来越多，整体服务效率逐渐下降；·发布/部署频率低，牵一发而动全身，新功能或问题修复的发布上线需要多方协调，发布时间一拖再拖。项目大则构建时间长、构建失败的几率也会有所增加；·性能瓶颈明显，一头牛再厉害也抵不过多头牛合力的效果，随着数据量、请求并发的增加，读性能的不足最先暴露出来，接着你就会发现其它方面也跟不上了；·影响技术创新：单体架构通常选用一类语言或一类框架统一开发，想要引入新技术或者接入现代化的服务是很困难的；·可靠性低，一旦服务出现问题，影响是巨大的。
分布式架构
分布式架构相对于单体架构而言，通过拆分解决了单体架构面临的大部分问题，例如性能瓶颈。假如单体架构是一头牛，那么分布式架构就是多头牛：
当单体架构出现性能瓶颈时，团队可以考虑将单体架构转换为分布式架构，以增强服务能力。当然，分布式并不是万能的，它解决了单体架构性能瓶颈、可靠性低的问题，但复杂性问题、技术创新问题和发布频率低依然存在，这时候可以考虑微服务。
微服务架构
微服务架构的关键字是拆，将原本糅合在一个应用中的多个功能拆成多个小应用，这些小应用串联起来组成一个与之前单体架构功能相同的完整应用。具体示意如下：
每个微服务可以独立运行，它们之间通过网络协议进行交互。每个微服务可以部署多个实例，这样一来就具备了跟分布式架构相同的性能。单个服务的发布/部署对其它服务的影响较小，在代码上没有关联，因此可以频繁的发布新版本。复杂性的问题迎刃而解，拆分之后架构逻辑清晰、功能模块职责单一，功能的增加和代码的增加也不会影响到整体效率。服务独立之后，项目就变得语言无关，评价服务可以用 Java 语言来实现也可以用 Golang 语言实现，不再受到语言或者框架的制约，技术创新问题得以缓解。
这是不是很像单一职责原则和接口隔离原则？
分布式和微服务并不是银弹
从上面的对比来看，似乎分布式架构比单体架构好，微服务架构比分布式架构好，这么说来微服务架构>分布式架构>单体架构？
这么理解是不对的，架构需要根据场景和需求选择，微服务架构和分布式架构看上去很美，但也衍生出了许多新问题。以微服务架构为例：
·运维成本高，在单体架构时，运维只需要保证 1 个应用正常运行即可，关注的可能只是硬件资源消耗问题。但如果换成微服务架构，应用的数量成百上千，当应用出现问题或者多应用之间协调异常时，运维人员的头就会变大；·分布式系统固有的复杂性，网络分区、分布式事务、流量均衡对开发者和运维进行了敲打；·接口调整成本高，一个接口的调用方可能有很多个，如果设计时没有遵循开放封闭原则和接口隔离原则，那么调整的工作量会是非常大的；·接口性能受限，原本通过函数调用的方式交互，在内存中很快就完成了，换成接口后通过网络进行交互，性能明显下降；·重复劳动，虽然有公共模块，但如果语言无关且又要考虑性能（不用接口交互）就需要自己实现一份相同功能的代码；
到底用哪种架构，需要根据具体的场景来选择。如果你的系统复杂度并没有那么高、性能追求也没有那么高，例如一个日数据量只有几万的爬虫应用，单体架构就足以解决问题，不需要强行做成分布式或者微服务，因为这样只会增加自己的工作量。
画好图
在需要表达关系和逻辑梳理的场景里，图永远比代码好。业内流行这么一句话“程序开发，设计先行”，说的是在开发前，需要对程序进行构思和设计。试想，如果连对象关系和逻辑都说不清楚，写出的代码会是好代码吗？
在构思项目时可以使用用例图挖掘需求和功能模块；在架构设计时可以使用协作图梳理模块关系；在设计接口或者类对象时可以使用类图做好交互计划；在功能设计时可以使用状态图帮助我们挖掘功能属性……
了解绘图的重要性之后，具体的绘图方法和技巧可翻阅本书（《Python 编程参考》）的工程师绘图指南章节展开学习。
起一个好名字
你还记得自己曾经起过的那些名字吗：
·reversalList·get_translation·get_data·do_trim·CarAbstract
起一个好的、合适的名字能够让代码风格更统一，看上去清晰了然。起一个好名字不单单是单词语法的问题，还会涉及风格选择和用途。具体的命名方法和技巧可翻阅本书（《Python 编程参考》）的命名选择与风格指南章节展开学习。
优化嵌套的 if else 代码
写代码的时候用一些控制语句是很正常的事，但是如果 if else 嵌套太多，也是非常头疼的，代码看上去就像下面这样。
这种结构的产生是因为使用了 if 语句来进行先决条件的检查，如果负责条件则进入下一行代码，如果不符合则停止。既然这样，那我们在先决条件的检查上进行取反即可，代码改动过后看起来像这样：
if "http" not in url: returnif "www" not in url: return
这是我平时常用的优化办法，后来在张晔老师的付费专栏中看到这种手段的名称——卫语句。
当然，这种简单的逻辑处理和 if else 控制流用卫语句进行处理是很有效的，但如果逻辑再复杂一些，用卫语句的效果就不见的那么好了。假设汽车 4S 店有折扣权限限制，普通销售有权对 30 万以内金额的汽车授予一定折扣，超过 30 万但在 80 万以内需要精英销售进行授权，更高价格的车折扣需要店长授权。这个功能可以归纳为根据金额的大小来确定授权者，对应代码如下：
def buying_car(price): if price < 300000: print("普通销售") elif price < 800000: print("精英销售") elif price < 1500000: print("店长")代码思路清晰，但存在的问题也明显。如果以后扩展价格和定级，会增加更多的 if else 语句，代码将变得臃肿。控制语句的顺序是固定在代码中的，如果想要调整顺序，只能修改控制语句。
那么问题来了，有比 if else 更合适的办法吗？
这时候可以考虑一种叫做责任链的设计模式，责任链设计模式的定义为：为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。
看起来有点绕，我们通过代码图加深理解：
处理类执行前根据先决条件判断自身的 handler 是否能够处理，如果不能则交给 next_handler，也就是责任链的下一个节点。上面的用责任链实现为：
class Manager:def __init__(self,):self.obj = Nonedef next_handler(self, obj):self.obj = objdef handler(self, price):passclass General(Manager):def handler(self, price):if price < 300000:print("{} 普通销售".format(price))else:self.obj.handler(price)class Elite(Manager):def handler(self, price):if 300000 <= price < 800000:print("{} 精英销售".format(price))else:self.obj.handler(price)class BOSS(Manager):def handler(self, price):if price >= 800000:print("{} 店长".format(price))
创建好抽象类和具体的处理类之后，它们还没有关联关系。我们需要将它们挂载到一起，成为一个链条：
general = General()elite = Elite()boss = BOSS()general.next_handler(elite)elite.next_handler(boss)
这里建立的责任链顺序为 General -> Elite -> BOSS，调用方只需要传递价格给 General，如果它没有折扣的授予权它会交给 Elite 处理，如果 Elite 没有折扣授予权则会交给 BOSS 处理。对应代码如下:
prices = [550000, 220000, 1500000, 200000, 330000] for price in prices: general.handler(price)
这跟我们去 4S 店购车是一样的，作为客户，我们确定好要买的车即可，至于 4S 店如何申请折扣，谁来授权与我无关，我能拿到相应的折扣即可。
至此，if else 优化知识学习完毕。
做到以上几点，相信你的代码质量和程序设计水平会有一个不错的提升，加油！
文章中提到的《Python编程参考》可在韦世东的技术专栏 https://www.weishidong.com 在线阅读。