本地大公司没有（就连排头的威科姆、新开普这些，都主要是吃补贴或退税的）。外地大公司的下级部门有不少，但大多属于前员工挂靠，很少有真正的独立部门。做软件外包（靠人脉找二包三包那种）的很多。做非科技公司里面 IT 人员的也不少。当然，上面这些加起来，可能还没做中国移动（中移在线）外包的多。

总体上来说，不是外包，就是花瓶，没事别回来。

@shenxj #29 注意，这个文档中的公式，除号跟乘号优先级相同，不是通常的先乘后除。

@shenxj #29 只交 15 年，等于白给，这里是权威回答，https://m12333.cn/qa/isyw.html 。

这个是改了之后的规则，改之前的规则，15 年那个不清楚，但是缴费基数那个在改之前是没有的，那时候是完完全全的基数越高越傻逼（当然现在这个仍然是基数高了傻，不过傻的轻点了）。

不考虑伦理的纯技术考虑：
1 ，终身制，等效于有效期直到死亡。
2 ，有效期的长度，是受失效可能性和续办成本综合影响的，生效可能性大的有效期短，续办成本高的有效期长。
3 ，至少目前的数据，婚姻的失效可能性很小。
4 ，婚姻的续办成本没有实际数据，但是从首次结婚的成本推算，续办成本会很高。

总结：单纯从技术性上考虑，终身制在目前也是最优解。

养老保险是最低交给 15 年才能享受养老金，不是交够 15 年就不用交了。养老金最重要的是基数部分，这部分只跟当地最低工资和退休时的连续缴费年限有关，只有这个才能跑赢通胀。至于缴纳的总和，那个是分 15 年返还的（不考虑通胀的话要多活 15 年才回本，考虑通胀的话这就是个零头，多活 100 年也回不了本）。

因为通胀的原因，你现在够 15 年，跟退休前 15 年，是不一样的。现在交够 15 年就停，那么到时候的基数就是前 N 年的最低工资，跟没有一样。

上面 16 楼说得对，你这不是入职别的公司做远程工作，而是个人自由职业。你这一年，在国内的工作环境下，只能算待业，只会影响发 offer 的的审批流程，不会影响入职流程的。HR 不在意的是你空挡一年或者接单一年，但你应该没跟他说清楚这是无正式工作的一年，他申请 Offer 的时候填成你正式工作一年（也可能 HR 清楚但为了让 Offer 更能顺利被审批故意填的），然后你入职的时候对不上了。

实际上来说，只要你没用代理入职交社保，在建立上，把这一年就空挡出来就行。在意空档期的早晚也不会要，不在意空档期的就避免了流程上的麻烦。

@morty0 #28 如果是异步处理，那么收到即表示成功，自然是收到就 ack 。但不是所有消息都要异步处理，这个具体要看是啥消息。ack 或者 死信机制，只对同步处理的消息有作用，异步处理的消息，需要有其他机制做异常处理。

1 ，这里支持的，应该只包含银联信用卡，不包含普通银行卡。仅能使用密码的借记卡，和信用卡（贷记卡）的密码功能，是中国特色，国际通用的无实物卡扣款认证方式是“卡号+有效期+cvv 码”（实物卡的是卡本身+签名，芯片卡连签名都不需要）。
2 ，战网亚服是台湾运营，台湾运营方式参照的是老美，而老美的订单处理方式超级复杂，显示订单完成，不一定就真完成了。虚拟物品，很有可能是付款只走个形式，7 天后才实际扣款，到时候要是扣款不成功就收回虚拟物品，如果是确定黑卡的话再额外做封禁处理。

境外支付，信用卡是前提，最好还是 visa 、mastcard 的卡（国内信用卡只分账户不分卡，任何银联信用卡成功之后，都可以随时申请 visa/mastcard 全币种信用卡）

@winglight2016 #25
只需要把监听消息和业务处理在应用内部解开就行了，不要拆成不同应用。监听消息和业务处理放在一个服务中，就只是底层的一个线程和异步线程池，对上层业务逻辑没影响。你要分成两个应用，先不考虑资源浪费问题，业务逻辑就搞复杂了。通常来说，映射转发也就几条规则，处理几十个队列，不管是业务逻辑还是性能上，都不具备独立出去的需要。只有映射转发规则多到需要专门的管理界面的时候，才能考虑独立出去。

关于实例 ID 这部分，这个重点是，消费者必须明确的告知消息中间件两个属性：一共有多少个实例，当前实例区分其他实例的标识（可以简单的只是个序号）。这是业务无关的，只跟运维实例的部署配置有关。配置的内容也不多，只需要消费者多加两个配置项，但是这俩配置项管理起来比较麻烦，因为它们的值不可预定义，只能在部署的时候动态决定，且每次部署都要重新决定。

单纯负载均衡或者随机分配的多实例消费者组的话，理论上是无需理会实例 ID 的。当消息不是自动均衡分配，而是按规则分区分配（比如说 1-5 给实例 1 ，6-10 给实例 2 ）的时候，就必须明确给出实例 ID 了。

我这里参考的是 Spring Cloud Stream （ https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream.html#spring-cloud-stream-overview-partitioning ）。请注意这些规则不是 Spring Cloud Stream 决定的，是消息中间件决定的，Spring Cloud Stream 只是做了上层抽象使其用起来更简单些。

@simonlu9 #17 生产者、消费者、消息中间件之间，只有消息中间件是服务器端需要维持多个连接，生产者、消费者都是客户端，只需要用一个线程维持一条连接，不管有多少消息队列。你把消费者监听消息，跟处理消息这两个阶段混在一起看了，这俩不能放到一个线程上同步搞，不然就算你一个队列一个线程，都要严重阻塞。通常来说，消费者收到消息后，是要把实际处理，再转交给异步执行器（对 Java 来说就是线程池）的，这样只需一个线程负责接受消息，一个执行器（线程池）负责处理消息。
@simonlu9 #18 如果是单纯的随机分配或均衡分配的消费者组的话，应该也是无需给出实例 ID 的。

微服务是跟着业务走，不跟着技术实现方式走的。消息队列消费者，绝大多数情况下，都不对应一种业务（具体的说就是实体、实体表、限界上下文这些），当然不能单独拆成一个服务。

问题 1 ，可以通过配置消费者组进行解决，一个消费者组，同一个消费者只会按调度规则扔给唯一的消费者。RabbitMq 、Kafka 都这只，Spring Cloud Stream 还提供了超简单的实现方式（不过运维要麻烦点，后面说）。

问题 2 ，我没明白你说得是什么，看起来像是系统升级时候的配合问题，这个解决起来稍微麻烦但也不是不能解决。生产者消费者如果不能同时更新，那么消息协议上，就要考虑多版本同时兼容的问题了。

最后说说运维麻烦的地方。多实例的时候，对于接口调用，是不用区分具体哪个示例的，负载均衡机制随便选一个就行了，所以实例无需明确 ID ，随机生成都可以。但是对于消费者组，就不能那么随意了，通常都是要明确给出实例 ID 的，不能随机生成，这会增加部署的麻烦成都。。

如果是一水草酸钙结石，那比石头还硬，碎不了的，碎石只能起到抹掉表层其他成分并顺便帮助挪挪位置的作用，最终还是要靠喝水加蹦跳排到膀胱。结石就两个环节回引起绞痛，通过输尿管中间一个细节，和进入膀胱前那个口。楼主看看彩超结果，是到哪里了，一般结石疼一次过后就到输尿管下端了，如果没有，那你后面还会有一次更痛的机会。注意一般来说，如果医生让你碎石，那就应该结石不大无需手术，都不是啥大问题，多喝水等排出去就行了。

我第一次结石，疼了一次到了输尿管下端就不动了，一年半以后才又折腾了一个月才搞出去。第二次不是一水草酸钙结石，是手捏一下就能碎的那种，结果直到排出去都没疼过。

不值钱的东西随便送。

正式的大礼就别送了。你要知道除了极个别国企外，程序员的领导，就算层层往上推到老板，甚至甲方客户那里，都特么是打工仔，送人家没法回的礼，这是给人添堵。

后端有两种，一种是真做后端，一种是主要做后端同时还要处理 Web 网站部分（包括但不限于前台网站和后台管理系统）。先去看看你们公司后端是哪个，如果是后者，头也不回的走人。如果是前者，再看情况考虑，但是要注意这不只是转编码语言，算转行业了，因为前后端（尤其是 Java 后端）的编程思想，是截然不同的。。

除了三星、索尼、摩托罗拉这种随时能跑路的，和苹果这种利税大户外，没有啥厂商能定住压力不往系统放屎。这个屎不一定是 ZZ 目的，反而最大的可能是毫无卵用只是用来给关系户过钱的。反诈这种半强制安装的方式，我就极度怀疑这是某个二代搞钱的项目。

有 NFC 支付等本地化需求的，只能上 iPhone ，或者拿 iPhone 当第二手机。没有的话，三星刷港版系统（国行系统没外部的屎但是三星自己会放屎，国行港版系统之间是无需 root 可通刷的）。

骑过几年小电驴的经验：电驴和摩托车，都是越大越舒服，除非有特殊需要，不要搞小的。小电驴除了不舒服以外，还有一个很大的问题，受限于体积空间，电池电压和容量都上不去，进而导致动力跟续航都不行。