什么就杀熟啊，你去 stackoverflow 花钱买啥了么

什么叫续上指定的类型？调用方法的时候不就把类型传进去了么？

我们是主用 helm 的，单个 helm chart 通用的放 values.yaml ，随环境变化的放各自 profile 的 values.yaml ，多个 chart 公用的通过环境变量用 helm 的 set 来做，目前体验还行

第一个如果用 spring 的话可以看看 spring cloud kubernetes，第二个如果是用 intellij 或是 vs code 开发的话，可以用 google 的 cloud code 来远程 debug

个人比较反感这类代号做版本的，又难记又不知道先后顺序。大公司项目里要有个出去做 ppt 的名号就算了，自己的项目弄个数字版本号不香么？

同问，为什么看上去感觉现在都是用的 redis? 除了 memcache 还有像 ignite, infinispan, hazelcast 这些都没人用么？

只说镜像的话，如果 imagePullPolicy 设成 ifNotPresent 的话是不会重新拉的，这也是默认和推荐的设置

Gitlab 只是做代码管理啊，加上 CICD pipeline 的一些功能。如果是项目管理我呆过的公司只要是 agile 的全部是用的 Jira，有些小痛点但是没大毛病

@FucUrFrd 大哥我没有去否谁，我们现在也是抽出来 import，我只是接了这个摊子第一次做微服务有点困惑，想问问这个架构的思路对不对

@generic 我觉得你说的很有道理，我们现在是每个微服务单独一个 springboot application，共用的实体类都丢一个公共模块里其他的 import，这个法子其实和楼里很多人说的一样，但我想着这样每个微服务不还是有公共的业务逻辑了么，就有点困惑

@huijiewei 对的，就是一两个人搞麻烦。其实麻烦还是次要，关键实体类一旦要动维护更麻烦，还有命名也容易混淆搞得头大

@FucUrFrd customer 这个例子比较大是这样的，但是如果重复的是比较小的一个类呢？比如身份证作为一个很小的类，偏偏多个地方都要用，像这种情况，微服务的理念是只要有多个服务依赖的业务逻辑类，就要拿出来再做一个微服务么？

@cassyfar 理是这个理，所有教程也都这么说，但是很多时候做起来还是有重复又太小不足以单做一个微服务的业务逻辑。举的 customer 的例子不太合适，但是很多时候还是会有这种情况。

@FucUrFrd 不是说那些 util，是指业务逻辑啊。只是个比方，假设微服务做的 ERP 系统里，一个管订单的和一个管记账的，可能都会用到 customer 这个类或者相关的逻辑方法？

minikube tunnel

@forPandaria 对 HBase 不敢大放厥词，但是我觉得 Hbase 和 mangodb 底层的设计是大相径庭的，不像 postgres 和 mysql, oracle 那样都是一个框架下能够比较，就像你说的分片，hbase 是以列为最小粒度来分片的，mangodb 按我理解还是比较粗的来分片，这咋比？而且 mangodb 的索引和 hbase 的 row key 也不是一回事，所以这两者应用支持层面上比较一下还行，要来比较性能只能说 Hbase 天生就是给特定的大数据场景而设计的

@YouLMAO 当然可以多列，但是只有按主列查询的时候才最快，如果想在别的列上加 filter 查询也会慢下来

等等这俩就不是一类吧，一个是 column 一个是 document，根本设计和应用场景就不一样怎么比？ hbase 是针对单列查询才快，你拿复杂多列查询到 hbase 上跑它也一样慢

考虑下 zookeeper+stateful set 呢？