成长团队@远足信使
这是《疯狂的麦克斯：狂暴之路》中的NUX ，但在Hike Messenger的成长团队中，这意味着完全不同的事情，即“新用户体验 ”。
因此，当臭名昭著的NUX启动给一些新用户时，状态更新服务就会停机，这与NUX无关。 这是因为状态更新服务和NUX具有共享的代码库的原因 。 NUX还尝试在影响我们的API服务器的特定情况下执行全表扫描。 如果有服务将表抽象化以保护它，而不是NUX直接访问该表，则可以避免这种情况。
增长的Growth API服务器是一个巨大的整体。 就像瑞士的军刀一样，它执行组织的所有功能。 类似地，巨型巨石就像池塘，如果将石头扔进池塘，产生的干扰会以波纹的形式传播到整个池塘之外。 同样，一项服务的行为异常会损害其他服务，从而妨碍整体服务器的正常运行时间。
它也有很多这样的问题，可以指出的主要问题是
弹性问题，一个系统中断会影响其他系统，例如NUX
扩展巨型独石的单个服务是困难的，它通常涉及生成整个系统的实例，该实例资源丰富，然后将需要扩展的服务流量路由到新生成的实例
庞大的代码库使开发人员望而却步
技术异质性实际上是不可能的，因为开发人员必须在现有堆栈中工作。 选择合适的工具处理手头任务时灵活性较差。 一个人不想让水管工进行手术吗？
由于所有开发人员都在共享代码库上工作，因此部署很麻烦，需要大量的协调。 有时会有无意的依赖关系，这会导致部署期间的信任度降低。 因此，除非必须提供一些重要的修补程序，否则仅在星期二和星期四允许部署API服务器的规则。
因此，微服务！
微服务规模较小，即范围 ， 功能和责任较小。 他们做一件事，但做得很好。 这使得它们极其易于部署和维护。
只要定义并遵守了使用服务的接口，对其内部进行的任何更改都不会影响消费者。 这使我们可以自由尝试不同的技术，并为任何服务选择合适的技术。 在将巨型Monolith API服务器分解为微服务时，我们注意到每个服务都必须：
- 将数据记录到分析中
- 发送数据包给用户
- 与sharded-redis互动
这导致大量代码重复，并且必须为每个服务检查和测试此重复的代码。 由于代码已被复制，因此为重复的代码添加的所有错误修复程序都必须复制到所有服务中，这使我们意识到代码是责任。 众所周知， 必要性是发明之母 。 因此，这导致了名为Pipy的服务的开发，该服务的主要目标是从所有服务中提取通用代码作为模块，并且安装这些模块应尽可能简单。
$ pip install
因此，Pipy
受pip启发的Pipy是一项服务，用于管理Hike开发的模块存储库。 在开发时就考虑了这些设计目标。
- 从服务中提取通用代码以避免代码重复
- 优化开发人员的生产力
- 模块仅在VPN内部可用
- 易于安装，没有devops依赖性，这意味着安装这些模块应该像$ pip install 一样简单。
Pipy的工作
想要添加模块的开发人员，将其上传到特定的github存储库。 侦听代码仓库更改的代码巡查员执行该模块的测试用例。 如果所有测试均通过，则将创建该模块的tar.gz并将其上传到s3。
想要使用这些模块的用户可以通过代理S3的HTTP服务器进行访问。
目前，pipy仅处理python，但我们计划将支持范围扩展到其他语言。
然后，我们发现了服务发现和监视方面的更多问题，将在后续文章中讨论。 🙂
[ 请继续关注以了解我们在此过程中遇到的很棒的工具所遇到的问题 ]
TL; DR
Hike的Growth的API服务器是一个巨大的整体，它存在各种问题。 因此，我们开始将整体拆分为微服务。 在微服务的开发过程中，例如代码重复的问题，服务发现弹出。 我们已经通过开发出色的工具克服了这些问题。 Pipy是本文中提到的对象之一。
