来源:InfoQ、 整理:褚杏娟
一般来说,整个工程团队在一个大型应用程序中工作(想像 Rails 应用程序中的整个站点),比推理微服务将以何种方式失败要容易得多。
无论如何,随着企业发展而拥有的分布式系统,引入数十个微服务进行推理已经很难了,更不用说数百个各有风险的微服务。
完全微服务化时,需要引入新的概念来处理“sprawl”。
重要的是,每个定制的基础设施服务或微服务都是债务 IMV 的极端版本。代码是债务,但服务是债务的极端版本。
尽可能地延长单体应用的使用时间。
服务从基础设施开始,而非应用程序。
如果要打破单体架构,打破大型应用程序,而不是小型服务。
认为每个新应用程序是贵公司的虚拟墙。
尽可能选择库而不是微服务。
推荐阅读
你好,我是程序猿DD,10年开发老司机、阿里云MVP、腾讯云TVP、出过书创过业、国企4年互联网6年。从普通开发到架构师、再到合伙人。一路过来,给我最深的感受就是一定要不断学习并关注前沿。只要你能坚持下来,多思考、少抱怨、勤动手,就很容易实现弯道超车!所以,不要问我现在干什么是否来得及。如果你看好一个事情,一定是坚持了才能看到希望,而不是看到希望才去坚持。相信我,只要坚持下来,你一定比现在更好!如果你还没什么方向,可以先关注我,这里会经常分享一些前沿资讯,帮你积累弯道超车的资本。