分布式服务架构：原理、设计与实战 - (EPUB全文下载)

文件大小：0.24 mb。
文件格式：epub 格式。
书籍内容：

分布式服务架构：原理、设计与实战
第1章　分布式微服务架构设计原理
第2章　彻底解决分布式系统一致性的问题
第3章　服务化系统容量评估和性能保障
第4章　大数据日志系统的构建
第5章　基于调用链的服务治理系统的设计与实现
第6章　Java服务的线上应急和技术攻关
第7章　服务的容器化过程
第8章　敏捷开发2.0的自动化工具
第1章　分布式微服务架构设计原理
自2000年以来，互联网企业以势如破竹的态势得到了飞速发展，以BAT为代表的互联网寡头更是迅速进军电商、搜索、社交等信息领域的各个市场，这些领域都涉及现代生活中不可或缺的网络化服务。
互联网企业从事信息技术的研发、生产和运营，与传统企业相比，互联网企业倾向于对特定的人群提供专用服务，这导致互联网产品多种多样、数量众多。由于传统的软件技术更倾向服务于企业，用户较少，所以传统的企业级技术无法满足互联网产品服务于海量用户的需求。于是，互联网企业对传统技术进行发展和演化，形成一套具有互联网特色的互联网技术。互联网技术以拆分为原则来满足服务于海量用户的需求，从架构上来讲，分布式、服务化（SOA）、微服务得到了深入发展，以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分解，采用分而治之的方法，达成用户需要的功能指标，并同时满足用户对高可用性、高性能、可伸缩、可扩展和安全性的非功能质量的要求。
本章主要讲解从传统的单体架构到服务化架构的发展历程，并讲解从服务化到现在流行的微服务架构的演进。这里提到的多种架构模式并不矛盾，而是一脉相承的，较新的架构思想是基于原有的架构思想在某个特定领域下满足特定需求演化而来的，因此，这里会更多地介绍这种架构适用的场景和服务的历史使命，并结合笔者在互联网企业中的实践经验，针对实施服务化后的系统遇到的各种问题，提出切实有效的设计思路和解决方案。本章最后会为读者介绍市面上流行的服务化组件的优缺点，帮助读者在实际项目中针对服务化实施做出正确的技术选型决策。
1.1　从传统单体架构到服务化架构
本节介绍从传统单体架构到服务化架构的发展历程。
1.1.1　JEE架构
JEE以面向对象的Java编程语言为基础，扩展了Java平台的标准版，是Java平台企业版的简称。它作为企业级软件开发的运行时和开发平台，极大地促进了企业开发和定制信息化系统的进展。
JEE将企业级软件架构分为三个层级：Web层、业务逻辑层和数据存取层，每个层次的职责分别如下。
· Web层：负责与用户交互或者对外提供接口。
· 业务逻辑层：为了实现业务逻辑而设计的流程处理和计算处理模块。
· 数据存取层：将业务逻辑层处理的结果持久化以待后续查询，并维护领域模型中对象的生命周期。
JEE 平台将不同的模块化组件聚合后运行在通用的应用服务器上，例如：WebLogic、WebSphere、JBoss等，这也包含Tomcat，但Tomcat仅仅是实现了JEE Web规范的Web容器。JEE平台是典型的二八原则的一个应用场景，它将 80％通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里，通过配置的模式提供给应用程序访问，应用程序实现 20％的专用逻辑，并通过配置的形式来访问应用服务器提供的模块化组件。事实上，应用服务器提供的对象关系映射服务、数据持久服务、事务服务、安全服务、消息服务等通过简单的配置即可在应用程序中使用。
JEE时代的典型架构如图1-1所示。
图1-1
JEE时代的架构已经对企业级应用的整体架构进行了逻辑分层，包括上面提到的Web层、业务逻辑层和数据存取层，分别对应图1-1中的Web容器、EJB容器和数据存取ORM组件与数据持久层（数据库），不同的层级有自己的职责，并从功能类型上划分层级，每个层级的职责单一。
在这一时期，由于在架构上把整体的单体系统分成具有不同职责的层级，对应的项目管理也倾向于把大的团队分成不同的职能团队，主要包括：用户交互UI团队、后台业务逻辑处理团队、数据存取ORM团队与DBA团队等，每个团队只对自己的职责负责，并对使用方提供组件服务质量保证。
因此，在分层架构下需要对项目管理过程中的团队进行职责划分，并建立团队交流机制。根据康威定律，设计系统的组织时，最终产生的设计等价于组织的沟通结构，通俗来讲，团队的交流机制应该与架构分层交互机制相对应。
JEE架构下典型的职能团队划分如图1-2所示。
图1-2
JEE时代下对传统的单体架构进行了分层，职能团队的划分也反映了架构的分层，架构已经在一定程度上进行了逻辑上的拆分，让专业的人做专业的事儿初见端倪，但是，每个层次的多个业务逻辑的实现会被放在同一应用项目中，并且运行在同一个JVM中。尽管大多数公司会使用规范来约束不同业务逻辑的隔离性来解耦，但是久而久之，随着复杂业务逻辑的迭代增加及开发人员的不断流动，新手工程师为了节省时间和赶进度，非法使用了其他组件的服务，业务组件之间、UI组件之间、数据存取之间的耦合性必然增加，最后导致组件与组件之间难以划清界限，完全耦合在一起，将来的新功能迭代、增加和维护将难上加难。
另外，由于JEE主要应用于企业级应用开发，面向的用户较少，所以尽管JEE支持Web容器和EJB容器的分离部署，这个时代的大多数项目仍然部署在同一个应用服务器上并跑在一个JVM进程中。
1.1.2　SSH架构
Sun公司是JEE规范制定的始作俑者，早在传统企业全面信息化的初始阶段，Sun公司看到了企业信息化建设的巨大市场，在制定JEE规范时，更注重规范的全面性和权威性，对企业级应用开发的方方面面制定了标准，并且联合IBM等大型企业进行推广。然而，在铺天盖地的规范和标准的限制下开发出来的符合JEE规范的应用服务器，不但没有简化在瘦客户环境下的应用开发，反而加重了开发者使用的成本和负担，尤其是早期EJB版本（2.0）的实现由于大量使用了XML配置文件，所以实现一个服务后的配置工作颇多，EJB组件学习曲线较高，又难以做单元测试，被称为超重量级的组件开发系统。
在JEE开始流行但没有完全奠定其地位时， ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。