没有“银弹” 之 微服务架构

陌若尘_c167 · · 612 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

没有“银弹”没有一种单纯的技术或管理上的进步,能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。

  1. 什么是微服务

微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。

系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。

每个微服务仅关注于完成一件任务并很好地完成该任务。

在所有情况下,每个任务代表着一个小的业务能力。

其实微服务本身不是什么新技术,只是随着业务的不断发展,对业务不断分层,不断拆分,形成的一种架构风格。

  1. 微服务与SOA

技术为业务而生,架构也为业务而出现。

随着业务的发展、用户量的增长,系统数量增多,调用依赖关系也变得复杂,为了确保系统高可用、高并发的要求,系统的架构也从单体时代慢慢迁移至服务SOA时代。

根据不同服务对系统资源的要求不同,我们可以更合理的配置系统资源,使系统资源利用率最大化。

微服务相比于SOA更加精细,微服务更多的以独立的进程的方式存在,互相之间并无影响,微服务提供的接口方式更加通用化,各种终端都可以调用,突破语言、平台的限制。

微服务与SOA都属于典型的、包含松耦合分布式组件的系统结构。

在围绕着服务的概念创建架构这一方面,微服务提供了一种更清晰、定义更良好的方式。

微服务的原则与敏捷软件开发思想是高度一致的,而它与SOA原则的演化的目标也是相同的,则减少传统的企业服务总线开发的高复杂性。

两者之间最关键的区别在于,SOA尝试将应用集成,一般采用中央管理模式来确保各应用能够交互运作。

微服务尝试部署新功能,快速有效地扩展开发团队,它着重于分散管理、代码再利用与自动化执行,专注于去中心化的部署方式,以自治的方式产生价值。

  1. 微服务的优点

复杂度可控:微服务在一定程度上解决了复杂性的问题。它会将一种怪异的整体应用程序分解成一组服务。虽然功能总量不变,但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动的API的形式定义了一个明确的边界,将业务的整体复杂度进行了分解。

独立按需扩展:这种架构使每个服务都能够由专注于该服务的团队独立开发,开发人员可以自由选择任何有用的技术,只要该服务符合API规约。

技术选型灵活:这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时,他们可以选择使用当前的技术。此外,由于服务相对较小,因此使用当前技术重写旧服务变得可行。

可用性高:微服务架构模式使得每个服务独立扩展。可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。甚至允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

  1. 微服务的缺点

代码重复:某些底层功能需要被多个服务所用,为了避免将“同步耦合引入到系统中”,有时需要向不同服务添加一些代码,这就会导致代码重复。

分布式系统的复杂性:作为一种分布式系统,微服务引入了复杂性和其他若干问题,例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等,开发人员需要考虑以上的分布式系统问题。

异步机制:微服务往往使用异步编程、消息与并行机制,如果应用存在跨微服务的事务性处理以及数据一致性问题,其实现机制会变得复杂化。

运维难度:微服务将一种怪异的整体应用程序分解成一组服务,可能需要构建/测试/部署/运行数十个独立的服务,并可能需要支持多种语言和环境,以及服务之间可能存在依赖性,会提高运维难度。

可测性的挑战:在动态环境下服务间的交互会产生非常微妙的行为,难以可视化及全面测试。经典微服务往往不太重视测试,更多的是通过监控发现生产环境的异常,进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

监控:对日志及性能的监控需要顾及多个服务器,实现方案更为复杂。

  1. 没有“银弹”

采用微服务架构,边界和职责明确了,模块高内聚低耦合,系统熵增就可以变慢,而且系统分拆之后,对于负责单个微服务的小团队来说,工作也变得很简单多了。这都是强调服务总线(ESB)的 SOA 和单体架构所不能的。

在合适的项目,合适的团队,采用微服务架构收益会大于成本。

然而有个词叫做“架构腐化”,系统不可能静止不动,随着业务的成长,市场的变化,系统总要不断增加新的能力,时间长了,最初简单高效的架构,往往就会变得极其复杂,臃肿不堪,即便最初的规范、分层都合理了,可扩展性、可用性、性能带来的复杂性也是难以避免的。

对传统企业而言,开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用,逐步探索及积累微服务架构经验,而非全盘实施微服务架构。


参考资料:

为什么时候微服务:https://blog.csdn.net/u012489091/article/details/78870492

认识微服务:https://blog.csdn.net/XinLiangTalk/article/details/98871638

欢迎关注【技术型项目经理】公众号。可获取软件行业动态、技术积累和项目管理理念文章分享。可在菜单中选择获取「PMP」、「高项」(信息系统项目管理师)、「CISSP」、「Python」、「GoLang」、「C++」学习资料。



有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:陌若尘_c167

查看原文:没有“银弹” 之 微服务架构

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

612 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传