微服务到底应该有多小？我终于想清楚这个问题了

聊聊架构 · 公众号 · 架构 · 2017-01-19 21:00

正文

请到「今天看啥」查看全文

所有与这个邮件系统相关的团队都必须紧密联系在一起，一旦应用有任何改变，（几乎）所有人的代码都会受到影响。这种应用被我们成为 All-or-Nothing。并且，我们只能选择运行/不运行整个系统，没法灵活的开启/关闭某些功能。对于某些团队，这样的结构就很好。但，我们假设，你的团队并不满足于这种架构，你们想要将整个应用切分成相对独立，有着自己生命周期的子应用/服务/库。

如何切分？首先，登陆/登出（或者我们成为授权系统）和用户资料这两块可以拆分成单独的服务。并且因为它们在安全上的特殊性，它们也应该被单独考量。邮件和文件夹两者联系很紧密，所以我将它们划分到一个服务（你也可以尝试拆分它们，尽管我个人并不建议）。接下来，如果我们有不同的通讯协议，如web interface、POP3、IMAP、 SMAP，我会将每个协议的实现部分拆成对应的服务。同样，信息存储，可以被抽离成独立的服务。通讯录加上它的UI与它的API可以被抽离成一个独立的服务。