01 | 是什么推动了单体应用到微服务架构的演进？

作者回复: SOA已经是用拆分服务的思想治理业务了，目前也确实多在一些金融银行业运用了，在这些行业里没有可见的必要性来替换到微服务架构，改造成本大不说而且容易破坏稳定性。但我了解的部分IT建设搭建的比较完善的银行，比如招行软开，已经在新系统中使用微服务化的架构了（不是银行业从业者如信息有误请指正）。 其实你可以把技术升级看做一个balance的过程，替换成本和必要性，学习成本实施成本等等，有时候对于已经构建在庞大业务体系之上的老技术栈，没必要为了追新而追新。就像阿里虽然开源了dubbo，但是淘系内部用的最多的还是稳如老狗的HSF，反而是PDD这类新公司在用dubbo技术，因为没有历史业务的包袱。而很多大公司历史包袱种，至今连上云都无法推行，就比如可口可乐的ERP系统始终不敢迁移到SAP的SaaS方案上。银行业一个道理。 技术发展总是不断向前的，就像当年使用SSH，现在使用spring boot，两者都能很好构建API，但是从开发成本和社区支持来看，新技术明显有更大的可持续性。当技术升级的balance在新技术一侧有了明显的优势，自然而然就会升级替代，就像很多传统企业逐步将单体集群化改为微服务化一样。

作者回复: 哈哈，这家公司简直是太优秀了！

作者回复: 用大白话讲，区别就是卷呗！其实SOA已经应用了服务拆分理念，但微服务更卷，应用一系列领域建模DDD等拆分理论，在领域治理方面粒度也更细。 当然在技术层面上为了达到独立开发测试运维的微服务价值观，在大厂实践中把“自立门户”这一点推行的比较彻底，一个比较直观的感受是，独立DB（很多SOA架构的系统也是共享DB），更加全面彻底的devops文化和容器编排方案，而且相比SOA来说微服务没有所谓的“企业总线”这一层，取而代之的使用服务治理方案构建端到端的调用（当然了在最外层还是有个网关的），诸如此类

作者回复: 用户并不知道自己的请求会路由到哪里，你在浏览器打开一个网址，在这个背后会请求DNS服务器做解析然后将请求路由到你的网关。我们以单体应用集群化部署来说，在网关背后你可以将集群里的机器配置到一个VIP里，也就是虚拟IP，可以通过keepalived LVS构建这个虚IP集群，也有的财大气粗的公司用贵的要死的F5来做，网关将请求转发到VIP上，在这个VIP池内通过负载均衡再把请求转发到处于live状态的单体应用节点上。当然，大型应用往往不止一个网关，他们还会再内部网络环境里构建多个zone，一个请求往往经历了多个网关转发。 对单体应用来说，承接更大的用户量可以通过水平扩展，可以认为集群中有很多很多的单体应用，多重影分身之术。 Forget it，马上讲微服务了，就不去想着单体应用啥事儿了，后面有的爽的

作者回复: paypal后面几千个微服务还是很庞大的，不过页面层为了安全因素，所以没用纯前端渲染的酷炫效果，很多地方用了bff层渲染。 贝宝那个大小周（每6周一次3天休假）不是永久政策，只是在疫情期间的特殊政策，大家理性看待哈。和其它外企比较的话，这边工作时间里还是安排的很紧凑的，但毕竟是外企所以涨薪嘛不能跟互联网公司比，这点也要有心理预期。PP在国内成立已经很久了，感兴趣的话，可以搜索公众号“PayPal招聘”，有看中的职位随时找我内推哈

作者回复: 下周开始是以每周三篇的进度来更新，前几课先来几道前菜，后面基本每篇都是动手做项目实战的系列。 实战项目的源码会开放的比较快，基础好的同学可以去把玩一下源码，从源码里也能了解下后面章节的内容。

作者回复: 这个选型是十分稳健的选型，整体用的netflix技术栈，我在之前也做了几年netflix，后面逐步转向alibaba组件的。netflix风格会感觉非常沉稳，alibaba组件挺跳的哈哈，能玩出花头。 碰到的技术难点可以在评论区交流，专栏里的内容未必会涉及的非常深入，在评论区可以尽情讨论

作者回复: 是的，seata是个双刃剑，非必要不要上这种重量级的一致性解决方案，事务性消息+补偿+日志表就是一种可靠廉价的一致性方案了。sentinel还是很好用的，但开源sentinel需要做一系列改造实现规则持久化，使用阿里云自有的服务就省点事儿了

作者回复: 回想起以前在SAP的时候，巨复杂的超级巨无霸单体应用也能过的很滋润，还贼稳定。甚至兄弟部门像successfactor这样的巨型saas也是单体，其实这种应用拆成微服务反而会搞的bug满天飞。能跑，能抗住，就成了管他是不是微服务呢，同学说对不对

作者回复: 限流熔断叫911，这个框架起名我要给个老铁双击666啊。起名字的这老哥是个人才