分布式服务架构：原理设计与实践（读书总结）

最新推荐文章于 2025-07-12 17:55:30 发布

原创

最新推荐文章于 2025-07-12 17:55:30 发布 · 3.2k 阅读

CC 4.0 BY-SA版权

文章标签：

架构的演进答题分为三个阶段：

JEE架构阶段主要划分为 UI交互研发团队（前端研发工程师）、后台研发工程师和DBA研发团队。SSH架构 阶段划分上与JEE架构阶段停留在相同层次上，不同点在于使用springMVC的划分性质，使用了Struts、Spring、Hiberate几个框架使得开发变得简单。
服务化架构不同于以上两种单体层次的架构模式，它解决了单体程序的高耦合和高并发程序无法突破瓶颈的限制。而SOA则是服务化的典型代表，它通过将服务进行详细的设计规划，拆分成一个个小型的服务，这些服务都必须在其定义的接口和契约上完成，并且通过诸如HTTP、TCP或IP等网络通讯协议进行网络通讯。典型的两种SOA实现方式是：Web service（注册发现模式）和 ESB（总线模式），现在大型互联网公司主流喜欢使用 Zookerper 和 Dubbo 的服务化架构模式。

SOA服务化是为了让每个服务职责单一、更简单和易于扩展，但存在历史遗留问题。而微服务架构则致力于松耦合和高内聚的效果，其强调每个服务的独立开发、维护、部署。

与传统的结构相比，微服务更加的灵活，可以平滑的进行水平扩展。具有子服务独立打包部署的特点，让更专业的人做专业的事。
与SOA服务相比较，目的不同、部署方式不同以及服务粒度不同。
- 目的性 SOA强调有效集成、历史应用集成、应用流程编排。微服务强调有效的拆分应用，实现敏捷开发和部署。
- 部署方式 SOA通过将组件化模块打成一个WAR包部署在一台应用服务器上。微服务采用敏捷扩容和缩容的docker技术来进行自动化部署。
- 服务粒度 SOA强调契约化，内部实现通常是粗粒度的。微服务将就单一职责原则，一般会将整体应用按照业务流程拆分为更细的粒度。

微服务的实现原理核心划分一下六个方面：

微服务职能划分讲求专业人做专业事，理论上一个服务需要一个团队去进行开发维护，而现实中不可能按照康威定律去执行的。
去中心化 就是尽可能不要去设置中心化管理中心，我们常用的Dubbo和Zookerper则是中心化管理模式，我们如果使用这种模式也要做到服务宕机的降级化处理，比如点对点的hessian远程调用。
微服务的交互通常来讲，容错就是我们消费方在消费服务是尽可能获取需要的数据，不要抛出异常，除非完全不能使用；消费者驱动模式就是消费方可以对提供者方提出具体的要求，提供者在对接口进行修改时要遵循此种约束；去数据共享通俗的讲就是不要公用相同数据库和缓存，每个服务需要有自己独立的服务器和缓存。
微服务组合模式 中我们最常用也是最应该使用的是服务聚合模式，它将基础服务可以组合成我们需要的服务，并且相比于分支模式，我们的服务调用结构可以更加的清晰明了。
微服务的治理我们需要有明确的模式，四种我们常用的模式都是我们需要进行分析和实践进行总结的。限流模式也是在高并发应用中经常使用到的模式。而失效转移模式中使用比较多的是补偿机制。
微服务的划分则需要我们根据业务和公司团队配置来进行合理的划分就可以了。