开发环境的成熟度、调试难度、日志查看、接口超时、异常处理，安姐列出的都是干货，都是系统拆分随之而来绕不过去的痛点。去年经历了公司系统的微服务化和一些模块的重构，看完文章后特别有感触。特别是修改代码后，有时本地需要起好多服务才能调试，一直是个痛点。公司只有一套公共使用的环境，上面部署的都是最新的主干代码。安姐提到google和facebook的开发环境比较成熟，他们是如何做到开箱即用呢？能否针对这些痛点，写写解决的方案？谢谢！

系统拆分是任何到发展到中后期公司必须经历的过程，前期因为商业模式试错抢占市场等会快速上线快速迭代，前期公司也没多少牛人，各方面都是业务优先，在不知道自己能活多久前提下，谈什么服务化技术优化都是扯淡。随时公司发展一般2-3年还没死，随着业务量越来越大，系统增加新功能、系统维护成本越来越高，系统变得越来越不稳定，DB一直挑战极限，这个阶段重构服务化是必须介入了，拆分和服务化的具体问题文中大体都介绍了，至于什么原则来进行服务化，如何去确定服务边界，如果确定上下文大小，哪些功能该放在一个服务中，这些需要好好看看DDD-领域模型设计。什么阶段做什么样的事，遇到事了不怕事，事后会发现这些不过如此。

灰度发布的时候，新旧的数据库 schema 不一样，怎么数据迁移咧？新老系统同时存在，也就意味着会对库有两种写法…这可如何是好

拆起来容易，合起来成为一体就有挑战了

不要为了拆分而拆分，视业务实际痛点，人员实际水平综合考虑

系统拆分最佳时机是否是软件设计时，如果系统已经上线，因为没有拆分带来了大量的弊端，比如迭代发版总出各种各样的连带问题，是不是要考虑下架构的问题了？

比较感兴趣的是airbnb是如何做技术创新的，因为经常看见你们各种技术大会都有露面，然后经常开源各种架构。不过你们的app确实做的好棒，不像国内的某程等眼花缭乱

好像每次都是提出问题，然后没有答案？应该举个实际遇到过的场景让我们参考，比如多大并发，什么业务，到达什么指标需要执行什么样的操作等等，希望作者能把实际经验分享一下

这篇文章写的非常好，从望京一路看到西二旗。解答了很多困惑。

公司刚成立，我们现在的代码库就是一个大的代码库，工程师人少，每个客户端，后台，前段也就一两个工程师，所以目前每次部署变更正式环境还是可控的，而且业务逻辑也还没复杂到说要进行拆分的时候～看了作者的观点后，还是要准备着以后可能面临的这些拆分问题～

Airbnb是开发人员写测试用例，执行测试吗？上线前不回归测试吗？

喜欢这种平易近人的文章 👍

最近浏览了后台架构，了解了下thrift、kafuka。看了安姐的分享，顿悟到thrift的无缝衔接。自己做的是桌面，了解系统的架构总觉是纸上谈兵。安姐的文章通俗易懂，因为有场景，即便是没从事过相关工作，也会理解相对深刻一些。
3ks

团队构架对拆分也会很大影响

能不能着重讲讲招人

朱老师，有开源的灰度发布工具和基于微服务的自动化测试工具推荐不