服务名的作用 给人用，标识一个服务，便于团队沟通协作 给程序用，用于围绕该应用的各种资源的命名，进而用于自动化处理，例如 给云资源命名， dev-fooapp-ec2 给k8s资源命名, fooapp-ingress, fooapp-deployment 给域名命名 foo.example.com 常见命名风格 camelCase, 首字母小写，后续每个单词首字母大写，比较常见应用于Java等编程语言 PascalCase, 跟camelCase 类似，但是每个单词首字母大写 snake_case, 比较常见于C，bash等大多数编程语言 kebab-case, 跟snake_case 类似，只不过用的是短横线-而非下划线 Pascal-Kebab-Hybride-Case, 微软powershell里见过 Pasical_Snake_Hybride_Case, 不常见 snake_kebab-hybrade_case, 看到有些头痛… Snake_Kebab-Hybrade_Case, 看到十分头痛… Snake_kebab-hybrade_Case, 脑袋要炸了… lowercase, 全小写，但是如果命名不好，会影响人肉眼可读性 命名风格没有好坏之分, 只有适合的场景, 以及最重要的是要 风格统一, 跟团队保持统一, 跟开源社区保持统一 服务名如何命名 首先前面提到，服务名一个很重要的作用是，用于构成其他资源名，进而我们可以通过资源名中包含的服务名来识别 该资源属于哪一个服务. 我们互联网服务中可能会使用到各种各样的资源，会使用服务名的资源包括但不限于 各种云资源命名，Tag名 容器/K8S相关的各种资源 程序、脚本的变量名/方法名 配置项 hostname，domain name 各种资源都会有各种限制，例如 domain name不允许有_下划线,同理会用到hostname或者domain name的地方，都不允许，例如aws的alb名 部分web服务器例如nginx，会默认drop掉name中包含_的http header, 因此http header 不允许有_ 有的场景严格区分大小写，有的场景仅能用小写、仅能用大写，或者会自动转换 几乎所有编程语言变量名，不允许包含短横线-， 例如你不能将变量名命名为 FOO-SERVICE-API 各种全文搜索引擎会对-进行分词, 因此，如果你搜索 foo-service 你会搜到包含foo或者包含service的结果，如果你搜索fooservice那只有fooservice结果，这个在日志搜索里经常遇到 由于以上限制存在，很多工具或者框架，会做一些自动转换处理，例如 snake_case变CamelCase, 大写变小写，自动去掉-或者_， 我们在编写脚本的时候也要按需做这些处理，以适应要求。

运行在kubernetes 的服务排错思路 https://containersolutions.github.io/runbooks/posts/kubernetes/crashloopbackoff