Posts About Email RSS

06 Oct 2017
如何用微服务制造问题

  • 如何使用微服务制造问题
  • 微服务成本
  • 理想的微服务平台

声称使用微服务架构的公司越来越多,一方面是云服务商的炒作,另一方面也的确是微服务带来好处的影响。 无论如何理解,在 twitter 上可以看到越来越多的程序员在吐槽微服务..

Microservices VS Monolithic

一方面,理论上微服务通过大事化小分而治之,可以解决开发周期长,旧项目难以维护等一系列问题,看起来非常万能。

另一方面很多人忽略了微服务的隐含成本,在实际实施后反而感觉处处不便。

实行微服务所需要的额外工作大致如下几类:

  1. 部署困难:需要搭建如 K8s, CloudFoundry 等应用平台来解决
  2. 测试困难:需要搭建 Jenkins 等 CI 工具来完成单元测试/集成测试
  3. 运维困难:需要在应用平台上搭建监控和告警服务
  4. Debug 困难:需要搭建日志服务接入平台,需要接入调用链分析工具
  5. 代码维护:微服务化后可能有些服务长期无人修改,对每个服务都需要建立良好的文档

可以看到,实行微服务需要优秀的运维团队支撑起应用平台(k8s)、监控告警工具、CI 服务、日志/调用链服务。需要开发团队做好文档化、自动化测试。

这些工作在单一应用架构时经常会被忽略掉,但是微服务中如果没有这些工具 debug、运维 等工作会非常痛苦,会浪费掉团队大量时间。

所以微服务的先决条件是团队需要拿出精力来维护以上基础服务。

很多小团队选择使用微服务架构,但后果往往是花费大量额外精力去支撑平台,或在基础服务不完善的情况下浪费大量时间 debug,实在不是一个好的选择。而大公司实行微服务带来的好处则相当明显,因为人数众多,维护平台的消耗几乎可以忽略不计。

有野心的公有云服务商应该将自身作为所有中小企业的微服务平台,提供微服务架构的所有基础服务,大量降低使用微服务的成本。这样微服务才会成为真正通用的架构模式。

从功能上来说 AWS(国外的那个..) 最接近理想形态。已经真正的可以让中小企业完全基于 AWS 基础服务来设计自己的后台架构。而其他服务商还多以 VPS + 数据库的形态出现。

如果以支撑微服务架构为目标的话,AWS 为首的公有云还都有一定的距离。

不知未来哪一家有野心的厂商可以提供真正实用的微服务公有平台。


Til next time,
jjy 2017.10.06

Posts About Email RSS