microservices 也就是分布式系统吗
发布网友
发布时间：2022-04-21 18:51
共1个回答
热心网友
时间：2023-10-22 17:37
定义在 Martin Fowler & James Lewis 的文章(参考[1])里给出了微服务架构的一个定义:微服务架构即是采用一组小服务来构建应用的方法。 每个服务运行在的进程中，不同服务通过一些轻量级交互机制来通信， 例如 RPC、HTTP 等。 服务围绕业务能力来构建，并依赖自动部署机制来部署。这个定义相对还是模糊，但还是勾勒出了微服务的一些关键概念：小，进程，自动化。起源从微服务的定义，我们感觉似曾相识。早在 1994 年 Mike Gancarz 曾提出了 9 条著名原则(参考[4])，其中前 4 条和微服务架构理念特别接近。微服务就像把 UNIX 哲学应用到了分布式系统（参考[3]）。Small is beautiful.Make each program do one thing well.Build a prototype as soon as possible.Choose portability over efficiency.小即是美：小的服务代码少，bug 也少，易测试，易维护，也更容易不断迭代完善的精致进而美妙。一个程序只做好一件事：一个服务也只需要做好一件好，专注才能做好。尽可能早地创建原型：尽可能早的提供服务 API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢再做。可移植性比效率更重要：服务间的轻量级交互协议在效率和可移植性二者间，首要依然考虑兼容性和移植性。可见微服务其实不是凭空产生的，它自有其历史的渊源。而在微服务之前的十年，大家经常谈论的是一个叫 SOA（面向服务）的架构模式，它和微服务又是什么关系？在 Sam Newman 的《Building Microservices》（参考[2]）一书中，作者对 SOA 和 Micorservices 的区别给出了定义：You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.你可以把微服务想成是 SOA 的一种实践方式，正如 XP 或 Scrum 是敏捷软件开发的实践方式。我对这个定义是认同的，面向服务架构（SOA）的概念已有十多年，它提出了一种架构设计思想， 但没有给出标准的参考实现，而早期企业软件业界自己摸索了一套实践方式 —— 企业服务总线（ESB）。 但历史证明 ESB 的实现方案甚至在传统企业软件行业也未取得成功，Martin Fowler 在文中说正是因为 ESB 当年搞砸了很多项目， 投入几百万美金，产出几乎为零，因此 SOA 这个概念也蒙上了不详的标签，所以当微服务架构出现时， 其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签，而直接称其为微服务架构（Microservices Architecture Style）， 让人以为是一套全新的架构思想，但事实上它的本质依然是 SOA 的一种实践方式。特征一个按微服务架构理念构建的系统应该具备什么样的特征呢？Martin 在其文章（参考[1]）中做了详尽的阐述，我这里简单归纳下。组件服务化传统实现组件的方式是通过库（library），库是和应用一起运行在进程中，库的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。按业务能力组织服务按业务能力组织服务的意思是服务提供的能力和业务功能对应，比如：订单服务和数据访问服务，前者反应了真实的订单相关业务，后者是一种技术抽象服务不反应真实的业务。所以按微服务架构理念来划分服务时，是不应该存在数据访问服务这样一个服务的。Melvin Conway 在 1967 年观察到一个现象并总结出了一条著名的康威定律（参考[5]）:Organizations which design systems are constrained to proce designs which are copies of the communication structures of these organizations.设计系统的组织，最终产生的设计等价于组织的沟通结构。传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为 UI、页面构建师等，中间层对应的角色为后端业务开发工程师，数据层对应着 DBA 等角色。事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。所以若要按微服务的方式来构建应用，也需要对应调整团队的组织架构。每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能。服务即产品传统的应用开发都是基于项目模式的，开发团队根据一堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。 而微服务架构建议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点：You build it, you run it.开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每日的交流反馈，来自直接客户的反馈有助于开发者提升服务的品质。
