Yelp公司总结的微服务架构的实践经验英文版：ServicePrinciples中文版：Yelp公司总结的微服务架构的实践经验ServicePrinciples服务设计的原则创建首先探讨系统的整体架构核实是否能够给现有服务添加新的功能考虑你的功能是否更适合作为一个库服务应由团队而不是个人负责管理服务是长期的commitment部署到分布式系统之前的考虑因素服务大点更好最小化服务调用链的深度最小化你的团队所拥有的服务数目接口接口要易于理解接口要尽可能健壮接口变更应该要向后兼容测试应该能够对任何接口变更进行自动化测试最主要的是测试你的接口运维服务的运行由你来负责引导客户的期望值故障计划补充材料创建首先探讨系统的整体架构在你开始考虑设计服务之初，也就是动手写代码和设计之前，和团队成员、其他服务领域的专家聊一聊。除了如何与现有的特性、产品以及服务如何适配之外，考虑一下你想要额外添加的功能。考虑一种最合理的组织整体功能的方式。有时候添加新功能意味着要对现有组件进行重组。我们希望避免那些简单的“append-only”服务架构，也就是说development只存在于新的服务中核实是否能够给现有服务添加新的功能在编写新的服务之前，应该核实是否现有服务不包括你的功能。它可能会与现有的功能存在冲突，处理相同的信息，或者只是在现有服务功能范围内的演化。另一方面，如果给现有服务添加新的功能会让服务的使用者感到困惑的话，最好就不要添加新的功能了。考虑你的功能是否更适合作为一个库尽管这篇文档是讲服务的，但值得注意的是一些功能更适合做成库。为了帮助大家更好的决策，我们介绍了库与服务之间进行取舍的一些经验:升级速度对于库来讲更适合哪些用户期望很长时间才进行升级的场合(通常数周或数月，甚至于数年)。一般来说，这要求功能本身相对小且自包含，所以本身变更的可能就小。相反，如果你还正在进行开发，或者你希望能够快速推送一些bug修订给用户，这样的功能更适合作为一个服务。这样功能就回更复杂一些，常常需要依赖外部的一些库。性能和可靠性库与调用请求的寻址空间一样，而服务则处于不同的网络地址。假使其他东西都是一样的，访问一个库要比服务更快更可靠。但是，如果功能对资源需求较高，比如CPU,内存和硬盘，那么作为一个服务能够让客户端的运行效率更高，能够使得服务所依赖的硬件独立于客户端的硬件而水平扩展。技术无关性大多数情况下，Yelp使用的是Python，有一些后...
