读书笔记--分布式服务架构对比及优势

      本篇是在上一篇的基础上，主要对共享服务平台建设所依赖的分布式服务架构进行学习，主要记录和思考如下，供大家学习参考。随着企业各业务数字化转型工作的推进，之前在传统的单一系统（或单体应用）模式中，每个系统都要做这些公共的功能或模块，比如用户管理，权限认证，日志，邮件，财务等等，随着企业各大应用系统的不断扩展，各垂直业务板块逐步沉淀形成各自的核心业务的数字化能力，提出了基于SOA理念的分布式服务架构，SOA理念主要特性有面向服务的分布式计算、服务间松散耦合、支持服务的组装、服务注册、自动发现、以服务契约方式定义服务交互方式等，本文介绍的ESB、HSF及微服务都是基于SOA理念，只是处于不同的发展阶段和不同的应用场合，目前比较流行的是部署到Docker中的微服务架构，实现一台机器计算、存储资源充分利用的同时，实现服务的解耦，提升应用的可扩展性、高效稳定性和应对变化的快速响应性等。以下重点总结了分布式架构有哪些？分布式架构带来哪些好处或优势，以及最新的去中心化微服务架构是什么，有哪些显著特征等。

一、分布式服务架构有哪些？

1.中心化服务架构：最有代表性的是传统厂商提出的ESB模式，相对于单一系统的“点对点”对接模式来说，ESB降低了系统之间的耦合性，让服务的提供者和调用者都可以通过企业服务总线(即ESB)实现服务的提供和接口的订阅及调用，为系统提供高效、稳定的集成，同时在负载均衡、服务管控方面提供了专业化能力。但这种服务架构带来一个致命缺点就是每次服务调用至少需要4次网络会话创建和数据传输（服务调用者--ESB--服务提供者--ESB--服务调用者）。如下图。

2.去中心化服务架构：最有代表性的是阿里的HSF(High Speed Framwork，戏称好舒服)，他除了具备上述ESB的所有特性之外，最重要的一点就是服务提供者和调用者之间进行服务交互时不需要任何路由中介，避免了中心点带来平台能力难扩展问题，以及潜在的雪崩影响，但对不同技术接口的支持、数据格式转换、服务动态路由等功能需要服务应用本身来考虑并编写，主要以服务契约的方式保障服务接口和稳定性，大大降低了服务发生变化给服务调用者带来的影响。这种服务架构只需要2次网络会话创建和数据传输（服务调用者和服务提供者之间），同时这种架构还具备服务的线性扩展支持和容错机制支持等。如下图。

二、分布式服务架构设计带来哪些优势？

1.降低不同模块开发团队的协同成本，业务响应更加迅速：不同功能模块间进行了清晰、稳定的服务契约定义，并由不同的转正开发团队负责完成并支持迭代。
2.大大降低系统间的耦合度及整体复杂度，各个开发团队可专注于各自的业务模块：应用或服务拆分后，由不同团队负责各自领域内的最专业的业务服务，能够提供更专业和更稳定的服务，同时对于新员工尽快理解自己负责的业务，尽快投入的生产业务中，便于接续传承。
3.避免了个别模块的错误给整体带来的影响：各个服务中心独立部署，避免了个别业务的错误导致整体业务的无法开展。
4.业务拆分后解放了对单数据库集群连接数的能力依赖：拆分形成的各个服务中心，后端都有自己独立的数据库集群，原来存储的数据库连接数限制得到了较好的解决。
5.做到针对性的业务能力扩容，减少不必要的资源浪费：从之前单一的WAR包到几十个上百个WAR包的独立部署，拆分后可以精准的根据业务需要进行能力扩容，资源得到充分利用。

三、最新的去中心化服务架构--微服务架构的典型特征

应该说微服务架构也是基于SOA理念提出的，只是微服务更加聚焦、粒度更小、更专业。微服务可以说是SOA理念落地的最佳实践。同时，微服务的服务设计要从业务维度进行划分，要考虑业务的前瞻性，并考虑服务能力的通用性和扩展能力等。另外，要向让微服务真正落地并持续生效发展，原有的组织机构，特别是企业信息中心等组织架构需要进行相应的调整优化，要围绕以服务为中心的持续运营、更新演变进行调整完善。
微服务具有以下典型特征
1.分布式服务组成的系统
2.按照业务而不是技术来划分组织
3.做有生命定的产品而不是项目
4.智能化服务端点与傻瓜式服务编排
5.自动化运维
6.系统容错
7.服务快速演化
可以说，企业的微服务建设是一个持续的过程工程，不仅仅是一个技术改变，更是一个业务不断演进的结果。微服务不是通过一个项目建设形成的，而是需要在业务发展过程中不断沉淀服务能力，而且只有沉淀到一定阶段，企业才能真正感受到微服务架构带来的长远价值，从而让企业飞得更高、飞得更远。