@virtuemartx 你说的很对！对于要去实现单个租户提出的需求确实是个问题，我是提出将客户的需求按标准功能来实现，通过所谓的“配置”或“开关”让客户自行选择是否使用该功能。毕竟在垂直平台中可能某些客户的需求正好也是其他客户想要的。。但就这提需求的这一点，就存在着很多弊端。。

一方面提需求的客户可能仅仅是平台的直接使用者——某个没有足够经验的行业运营小编，他们提的需求有时候质量真的很差也很天真，前两年产品经理也傻乎乎的客户提啥就安排去做啥，使得这产品质量逐步下降；

另一方面这种伪 saas 的模式是卖的平台产品！（你们见过几个 saas 是这样的？大多都是工具型的吧） 这么一来，工作量可就很大了，首先光业务需求上，不同地域地区客户的行业运营模式不一样，也就导致你这平台不能只支持一种运营模式，各种需求堆叠，都通过各种配置开关实现，所以现在整个系统内的配置开关非常多。。也就又导致了产品非常的臃肿，像 26 楼回复所说，由于目标客户群体少，后来连非社区门户类的个人自媒体客户也都接入进来，他们本身人力缺乏团队较小，这些客户看的这系统头都晕了。。

大多数客户需求都可以按标准功能做进这系统，但也有一些真的很定制化的功能，对于这些功能一开始我基本是拒绝的，毕竟考虑到后续的维护和管理成本，而领导那边、产品经理那边只顾着满足客户需求，不考虑的成本问题的。毕竟这奇葩的模式产品一旦卖了出去，后续的功能迭代、需求开发都是不收钱的，所以基本是个无底洞了，战略层面上没有任何策略的。

再再后来，还是因为这种卖平台的模式，客户需求已经不仅仅停留在了垂直行业业务层面上，客户会对技术层面提出需求，比如带宽想要多少、域名绑定与解析、域名证书的配置、CDN 线路等等问题，这类问题产品经理就懵逼了，不懂技术只会规划垂直业务，所以基本不会管这些需求，所以把这些需求扔给技术。。那么我就没办法了，做起了技术功能的规划和开发。。真是比较蛋疼的。。做成 IaaS 还是 PaaS 了。

---

说到测试，我们是没有技术测试的，单纯的人工端到端测试，做完了部署到测试环境中，产品经理用浏览器访问点点功能觉得没问题就算测试过了。在后面的几年里，我也尝试过写单元测试，但实际上业务端的开发基本是没时间写的，天天都是需求怎么会有时间，一般中小型企业很难有全面测试吧。所以目前只在一些 sdk 包中写一些单元测试，这已经是尽力了。

我们一开始是一个客户一台服务器+一套系统代码部署，需求是刚才所说的统一在代码中作为标准功能开发，受版本控制，所以不会单独给某个客户代码做修改。否则这管理起来太难了。但这种伪 saas 形式如今被我改造掉了，目标是向着一套代码包含多租户的形式进行改造，而且以前的单机部署方式在代码上线更新时非常非常的费时费力（使用的是 ansible ），所有租户做更新基本要个十几或几十分钟，甚至还会出错。现在用 k8s 对所有客户系统做一轮更新只要一两分钟。更为神奇的是，现在连运维岗的人都不需要了，由我拉着另一位还算可以的开发岗的同事兼做 k8s 运维了= =！

@Valid 佩服老兄！还得学日语= =

@changepll 主要是自己能力还想再提升一把，另外也想了解一下其他企业的各种情况（如文化氛围、管理制度、商业模式等等），毕竟毕业后就在这公司都没了解过其他企业是什么样的。。

通过大家的评论，大概的了解了。。都比我之前自己定的 16k 的目标高 = =！

@ligthdawn 你这。。。看你们业务啊，docker 分配影响到的只是服务器资源，你们业务需要对每个租户进行服务器资源限制？一般这种情况我个人觉得需要额外研发，就像我文中所说的我们基于 openresty 开发了带宽限流，因为我们业务需求上需要对租户进行带宽限制，所以把一个大的共享带宽通过额外的研发限制分配给单个租户。。那服务器资源也是一样，我们公司目前是没有对服务器资源如 cpu 内存做限制的。。而且一般情况也不建议对租户限制服务器资源，毕竟你不是做 IaaS 或 PaaS 的。。。其他你说的资源瓶颈问题这个可以看一下 k8s 相关内容，什么容忍性、亲和性调度之类的，好处那是比单台服务器部署多。。

@king2014 我靠！老哥！你是明眼人啊！我也是这么认为的

@z5864703 好吧。。我觉得上海和深圳应该是一个级别的吧。。如果也都是拧螺丝的一大把，那只能期望于高薪资了，拧螺丝就拧螺丝吧。。毕竟之前招聘时也见过从上海回常州的，能力比较差，但在上海的薪资还比我都高。。哎

@yywudih 哈哈哈 你以为呢

@zoharSoul java 和 golang 我也考虑过，常州 java 整体薪资比 php 高，但 go 也没几个，如果写 java 的话我就待在这了。。但是没实践经验。。所以想要靠着 PHP 开发和衍生出来的其他能力经验去上海找个高薪资的，然后看看有没有机会在那边转个 java 再回来。。

@sryanyuan 对啊，常州互联网行业是真不行。。我们公司算本地互联网行业的龙头了还是这样子。看了下隔壁无锡苏州确实比常州好

@ershisi 这个不怎么好说啊，大厂的我也看过，一方面我是属于接触面比较宽的，单在 PHP 上感觉不够自信，尤其是面试底层网络、协程之类的问题的话。。。另一方面大厂加班情况不是太了解。。有没有啥推荐的

@ben1024 看起来不错，回头我研究一下

@useben 这些都有，但日志没做满，一些问题出现在没做日志的地方，但不出问题的话感觉这些日志太占空间了。。

@Vegetable 好吧，就是觉得一些地方做日志，平时基本没啥问题，但日志大量被产生，收集的贼多，感觉像是在浪费磁盘。。

@wangxiaoaer 我感觉你这样的理解也是正确的

@manami 看一下 12 楼我的问题捏，对于一个微服务架构的体系下，一个服务可能看做是一个应用。但是从整体上看呢，在商业概念上可能我们是做家居和房产的两个平台，下面都是微服务架构，那哪些可以称之为应用？哪些可以称之为项目呢？

同样举例如美团，美团的外卖平台算一个项目吗？那美团的打车也算一个项目吧？一方面我是不是可以称美团外卖 app 是一个应用？另一方面打车和外卖的用户数据是从一个底层服务来的，这个服务也是一个应用是吧？

@codepm 然后再进阶一下。。我不知道你有没有了解过，不过我先问一下，有两种情况，一种是放大看，一种是缩小看。
1. 假如我们采用了微服务架构的方式，放大了看里面，每个服务是不是又是一个应用？而项目依旧是房产？
2. 假如我们又要做一个家居垂直行业平台，缩小了看，那么我们的房产还算是一个项目吗？还是从整体上来看家居+房产算是一个新的整体的项目，房产和家居成了应用的概念？

项目和应用的概念称呼是不是该随着规模的大小而变化？

@codepm 你这么一说我好像有点搞明白了。。因为我们是一个做互联网房产垂直平台的，包含了好多端如 pc、wap、小程序、APP 等，而平常我们只称呼这是“xx 端”。但其实每个都是一种应用是吧？整个房产平台就是项目吧？

/home/www

@msg7086 好吧，大概了解了，最主要的应该还是给使用的客户端、依赖端看的，那自己内部应该没必要使用了