Microservices

微服务意味着把一个应用拆分成许多个小服务，每个服务负责业务的一块，且每个都能独立部署。你得到的不是一个所有东西都在同一进程中运行的程序，而是一支通过网络彼此通话的服务舰队。这个承诺是真实的：团队可以独立交付，你可以只扩展需要扩展的部分，而且一个服务可以故障却不拖垮整个系统。

代价同样真实，而且通常被低估。一旦你的函数调用变成网络调用，你就有了一个分布式系统，而分布式系统很难。你继承了网络故障、延迟、分散在许多数据库中且没有简单事务的数据、服务之间的版本控制，以及运行、监控和调试许多活动部件而非一个的运维负担。一个过去只是一段堆栈跟踪的 bug，现在变成横跨五个服务和三个队列的追踪。

诚实的立场：大多数初创公司应该从单体（monolith）开始。一个结构良好的单一应用构建更快、调试容易得多，而且完全有能力把你带到真正的营收。当你有一个具体理由时再拆分成微服务，比如团队大到一个代码库成为瓶颈，或一个工作负载确实需要独立扩展，而不是因为微服务是流行的答案。过早的微服务，是小团队把一个难题变成十个难题的方式。

Polity 运行在七个微服务上，这对它的规模和团队结构而言是正确的决定。这正是要点：架构应当跟随问题和组织架构图，而不是一场会议演讲。把边界画在它们确实能降低耦合的地方，并接受你画的每一条边界都是一次你现在必须捍卫的网络调用。