使用微服务，你考虑好了吗？(2)

说它不正确,是因为这种方法不仅仅能用于微服务,更可以用于单体服务.你可以为你的单体应用创建逻辑集群,只处理某项业务的流量.比如API请求、前端仪表盘和后台任务服务器可以在相同的代码库里面,但并不需要每个都处理三个不同的业务.

好处就像是微服务一样,不同的集群承担不同的工作负载,可以单独扩容一个集群来应对流量的激增.所以,虽然微服务提供了很多方法,你同样可以把这些方法引入到单体应用中去.

到底什么时候应该使用微服务架构呢?

“当你准备好成为一个工程化组织时.”

最后我想说,时间恰当时,可以迁移至微服务(或者你知道这是否是正确的开始方式).

实现微服务的一个至关重要最坚实可行的重要步骤是,你能够正确理解你正在工作的领域.如果你不理解它,或者你正在试图弄清它,那么微服务则是有害无利.当你真正深刻地理解你的领域,知道边界在哪里依赖是什么,那么迁移至微服务架构才有可能是正确的选择.

另一个重要的事情是处理你的业务流,具体来说,就是业务如何进行分布式事务.如果你知道每一类请求通过系统的路径,并且了解每个路径上可能失败的位置、方式和原因,那么你可以着手开始构建一个处理请求的分布式模型.

除了了解您的业务流之外,还需要监控你的工作流程.监控是微服务和单体之争的事情,但是它应当是你的工程化的核心工作之一.因为你需要大量的数据来发现系统为何性能不佳甚至引发错误.只有你能找到一个可靠的方法来监视系统的各个部分,你才可以知道如何来优化它.

最后,当你真正可以向研发团队和业务方展示价值时,迁移到微服务才可以帮助你承担增长的业务、扩容和赚钱.虽然说尝试新鲜事物是有趣的,但是你真正开始前,应当明白对于许多公司来说,什么是他们的底线.如果因为一篇博客文章告诉你单体应用不科学,而导致新功能的延期交付进而影响到业务收入时,你必须去迎合你的业务.有时候这些权衡是值得的,有时候不是.能正确认识到当前应当着力解决的问题,并以此来做技术的权衡,长期来看才是真正有益的.

最后的最后

希望下次有人提出微服务架构时,你能想明白实施微服务架构的条件是否成熟.就像我一开始所说的,本文并不是来说微服务是糟糕的,是希望你开始之前,能够避免这条道路上会出现的一些坑.

如果你问我应当怎么做,我建议通过代码中清晰定义的模块结构来建立内部服务,并且随着时间的推移,逐渐将他们划分成独立的服务.这种方法不一定是最好,但也不失为避免烂代码进入系统的一个方法.当你准备好时,它能很快地帮你迁移到微服务架构上.

文章出处：Docker(订阅号ID：dockerone)

（编辑：ASP站长网）