别的不评论，第一条没问题呀。接口对接时一旦涉及任何改动，你又做不了主，擅自改出问题责任必然是对方的，老老实实带上自己这边能说话算数的才是王道。别说外包了，正式员工有时也是这样，说话不管用等于没说。

现在稍微重要点的业务都得双机热备吧，如果连灾备都不用考虑，我更怀疑是否有必要用“分布式架构”。

AnyProxy

这样设计最大的一个问题是，理论上 CURD 服务变动了，对上层所有服务都可能会带来未知的影响，因为你不知道有几个消费者在使用这个服务。CURD 服务只做代码追加还好，一旦涉及代码修改，鬼知道会出什么奇奇怪怪的问题。

一般把增删改查用独立服务实现是因为微服务数量众多，每个服务单独连接数据库会对数据库连接构成压力。贵司把所有数据库 curd 操作放到一个服务里边，明显不是因为这个原因。

根据我的理解，微服务在数据库层面，一般应该是先根据业务功能进行垂直拆分，也就是分库分表，如果数据库连接有压力，再考虑把 curd 操作独立成服务，或者应用数据库代理。

贵司这么搞，感觉像是为了做成一个类似数据库代理的东西，以后分库分表对上层就透明了。但是如果业务层面不先做拆分，一旦 SQL 复杂了些（比如多表联合查询），最开始的愿望未必能实现。

下班前不要提代码，节日前不要发版，楼主还年轻啊，需要磨炼。

滴滴一下，马上出发。还好手里边有个绿牌[手动捂脸]

公司规模不够大，业务不够复杂，谈中台是没有什么意义的。企业中台本身是为了解决企业内部烟囱式系统林立、系统重复建设、相互之间缺少调用关系而出现的。小公司强上中台，意思不算太大，做好基础服务拆分就行了。

如果不是访问量巨大，或者业务庞杂，硬上微服务意义不算太大。如果考虑以后的可扩展性，只做服务化也足够了，后续再拆也不算困难，步子太大的话容易扯着 D。

@dven 大概率不是因为成本原因，对世纪互联 /快网这种卖带宽公司来说，拿冗余带宽就把事儿办了，服务器更是不值钱。主要是在这个网络安全大于天的年代，监管成本太高，搞不好就有全业务中断的风险，根本不可能给你那么长时间的公告期，毕竟现在已经不是十年前了。

@ColinZeb 看他的公告，应该又是和上次停止解析一样的，灰产或者不法网站引起的，监管成本太高。总有几粒老鼠屎，生生坏了一锅粥。

能坚持这么多年已经很不容易了。这年头免费服务两面不是人，一头是不断增长的监管成本，搞不好连带其它付费服务一起受影响；一头是免费用户，只有成本没有利润，而且这些人里边总有几个既不愿意花钱还 BB 来 BB 去的，两头不落好，坚持下去才难。

要么运营商，要么自建，上游运营商+Google Public DNS。

选其他服务器的朋友，就不怕有 CDN 的网站给你分配一个异网节点么？对 EDNS 如此自信？

除非你能在不影响工作的情况下教会其他人，否则这种建议等于没说。