无
作者回复: 嗯,大规模微服务需要paas平台支撑。
作者回复: 比方很多后台批处理服务,定期要对批量数据进行处理,这时数据量很大,不可能弄个大调用去数据源取数据,只能复制一份并定期或实时同步变更
作者回复: 是方向,但对研发运维要求也高,需要一定研发定制能力,devops文化等
作者回复: 有一些强一致性技术手段,这边回复难展开,会另开专题讲,最终一致性是业界一般性实践和推荐思路。
作者回复: 先理解微服务架构的利弊,具体权衡要在企业的实际上下文(企业的技术/架构/组织/业务)中进行。
作者回复: 如果是不兼容的升级部署,这个时候就不能用简单的分批灰度发布,需要做特殊处理,先做严格内部或者beta用户测试,然后再考虑如蓝绿部署,一把切换,有问题一把回退。 一般尽量考虑兼容升级,通过代码开关控制新业务逻辑的打开或者关闭(可以和配置中心如Apollo配合),这个称为开关驱动开发(Feature Flag Driven Development)这样风险更小,而不是单纯靠运维部署。
作者回复: A和B团队都有订单数据的概念,但格式和用途是不一样的,比方说A团队维护电商线上web订单数据,B团队维线下ERP系统订单数据(同时包括线上web和线下门店),发货以线下ERP系统为准,那么线上订单就要定期同步到线下。
作者回复: 具体要不要把服务分那么细,每个都独立部署在独立的虚拟机或者容器中,要看你的业务复杂性和规模,还有团队规模,一般公司越大分得越细,否则会有效率问题。小规模的话,搞那么多服务反而增加复杂性,做好基本的模块化就好了。
作者回复: 多谢支持🌹