hongweipeng 发布的文章

[转]Python后端架构演进


原文链接:https://zhu327.github.io/2018/07/19/python后端架构演进/

来腾讯之前在前公司做了3年的后端开发, 经历一款SaaS产品从0到10(还没有到100, 哈哈哈)的过程, 3年间后端的架构逐步演变, 在微服务的实践过程中遇到的问题也越来越多, 在这里总结下.

产品是一款服务于人力资源的SaaS在线服务, 面向HR有Web Android/iOS 小程序多个客户端, 后端采用RESTful风格API来提供服务. 主要使用Python语言, 方便快速迭代.

架构的演进经历了4个大的阶段: 1. MVC 2. 服务拆分 3. 微服务架构 4. 领域驱动设计.


用Python实现读写锁


起步

Python 提供的多线程模型中并没有提供读写锁,读写锁相对于单纯的互斥锁,适用性更高,可以多个线程同时占用读模式的读写锁,但是只能一个线程占用写模式的读写锁

通俗点说就是当没有写锁时,就可以加读锁且任意线程可以同时加;而写锁只能有一个线程,且必须在没有读锁时才能加上。


__eq__ 中包含着隐藏关系


相不相等我说了算,本文讨论的都是在python3的环境下

起步

__eq__ 是用来重载操作符 == 的;相对的,__ne__ 用来重载 != 。这两个魔术方法存在一个容易忽略的隐藏关系,就是当类中定义了 __eq__ 而没有定义 __ne__ 的时候,对于 != 操作会取 __ne__() 的反向结果。

但反过来就不成立了,如果定义 __ne__ 而没有定义 __eq__ ,对于 == 操作则会进行默认的行为。也就是说 x != y 不一定就是 x == y 的相反结果。它们之间并不存在这样的隐藏调用的关系。

所以,绝大多数情况下,重写 __eq__ 方法就够了。

其他比较操作符:

object.__lt__(self, other)
object.__le__(self, other)
object.__gt__(self, other)
object.__ge__(self, other)

也都不存在这个关系。没定义的操作符会抛出 NotImplemented 异常。