
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了微服务架构的一些基础知识与特征等内容,而本文我们就再来学习一下,微服务架构实践方法都有哪些。
去中心化治理
对于微服务来说,并不要求所有的微服务都采用同一种语言,同一种架构方式来进行。通常来说了保证系统和代码的可维护性,一般来说是要求所有的服务都使用同样的编程语言和架构。
但是对于特别的部分,比如对性能要求特别高这样的需求,那么可以尝试考虑一个不同的编程语言。
总的来说,就是每个微服务的团队对他们自己的服务负责,只需要保证对外的服务和接口的正确性即可。
去中心化数据管理
对于单体应用来说,所有的数据都放在一个数据库中。如果对微服务进行了去中心化管理,那么相应的数据库属于各个微服务组,所以在理论上微服务的数据也应该是去中心化部署的。
但是这样多个数据库照成的后果就是各个数据库中数据的一致性。在单体应用中,这个问题可以通过数据库事务来解决。但是对于微服务来说,分布式事务是不可行的,或者说代价太大。一般来说对于微服务来说,我们需要保证数据的终一致性。
通过补偿机制来进行数据的校验和修复。
自动化部署
自动化部署的目标就是持续交付,对于微服务来说,多个服务的自动化是必不可少的。通过自动化编译,自动化测试,自动化集成和自动化部署,可以大大的减轻开发团队和运维团队的任务。提升开发效率。
对异常的响应
使用服务作为组件的结果是,应用程序需要设计成可以容忍服务失败。任何服务调用都可能因网络或者其他的原因导致不可用而失败,所以必须尽可能优雅地对此做出响应。
于单体服务相比,这需要引入额外的复杂性来处理它,所以可以看做是微服务的一个缺点。开发团队需要尽量多做异常测试,以保证在极端的环境中程序的正确性。
由于服务随时可能出现故障,因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。微服务应用程序非常重视应用程序的实时监控,检查架构元素(数据库每秒收到多少请求)和业务相关指标(例如每分钟收到多少订单)。语义监控可以提供错误的早期预警系统,让开发团队跟进和调查。监控对于快速发现不良的紧急行为并加以修复至关重要。
我们希望看到针对每个单独服务的复杂监控和日志记录设置,例如显示启动/关闭状态的仪表板以及各种运营和业务相关指标,还包括有关断路器状态、当前吞吐量和延迟的详细信息等。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。