fwq

如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。 无架构，不系统，架构是大型系统的关键。从形上看，架构是系统的骨架，支撑和链接各个部分；从神上看，架构是系统的灵魂，深刻体现业务本质。 架构可细分为业务架构、应用架构、技术架构，业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。   如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。本文基于作者在大型互联网系统的实践和思考，和大家一起探讨应用架构的选型。 一、应用架构本质 应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面，应用架构定义系统有哪些应用、以及应用之间如何分工和合作。 分有两种方式，一种是垂直分，按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另一种是水平分，按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。 应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。 应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。 应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。 系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。 常见的应用架构有多种，下面根据系统拆分方式，以及如何平衡业务与技术的角度进行分析，讨论各自的适用性，给企业应用架构选型提供参考。 单体式应用 1、架构模型 系统只有一个应用，相应地，代码放在一个工程里管理；打包成一个应用；部署在一台机器；在一个DB里存储数据。单体式应用的架构如下图所示： 单体式应用采用分层架构，按照调用顺序，从上到下一般为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取。 单体应用在水平方向上，上下层之间职责划分清晰；但垂直方向上缺乏清晰的边界，上下层模块之间是多对多的依赖关系，比如业务模块1 （图中BO1）可能调用数据层所有模块DAO 1~3， DAO1也可能被业务层所有模块BO1~3调用。 单体应用通过水平分层，降低了业务复杂性；同时模块之间是进程内部调用，技术实现简单。 但单体应用对系统的切分不彻底，只有水平切分，并且是逻辑上，因此适合业务比较单一，但深度上比较复杂的系统，比如TCP/IP网络通讯，从应用层/传输层/网络层/链路层，层层推进，类似这样的系统可以方便地增加水平层次去适配。 对于广度上复杂的业务，由于缺乏垂直切分，强行把不同业务绑定在一起，整个系统神散形不散，带来一系列问题。比如OTA网站包含机票/酒店/旅游等多个垂直业务板块，每块都比较独立，就不适合放在一起开发维护。 2、优缺点 单体式应用的优点和缺点都很鲜明，如下图所示。 单体式应用的优点明显： 现有IDE都是集成开发环境，非常适合单体式应用，开发、编译、调试一站式搞定。…

这里主要介绍几种常见的架构设计理论和原则，常见于大中型互联系统架构设计。 一、CAP理论 1.1、什么是CAP？ 著名的CAP理论是由Brewer提出的，所谓CAP，即一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。 Consistency（一致性）：更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致（All nodes see the same data at the same time）。这里的一致性，一定要和传统的RDBMS中的事务一致性区分开。 在传统的RDBMS中，事务具有ACID4个属性，即原子性（Atomicity），一致性（Consistency），隔离性（Isolation）和持久性（Durable）。   ACID是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性（Consistency）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。 持久性（Durability）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。 MIT的Gilbert和Lynch在证明CAP的过程中改变了Consistency的概念，也就是将Consistency转化为Atomic。Gilbert认为这里所说的Consistency其实就是数据库系统中提到的ACID的另一种表述：一个用户请求要么成功、要么失败，不能处于中间状态（Atomic）；一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态（Consistent）；未完成的事务不会互相影响（Isolated）；一旦一个事务完成，就是持久的（Durable）。 Availability（可用性）：读和写操作都能成功（Reads and writes always succeed）。…

TCP与UDP基本区别 基于连接与无连接 TCP要求系统资源较多，UDP较少； UDP程序结构较简单 流模式（TCP）与数据报模式(UDP); TCP保证数据正确性，UDP可能丢包 TCP保证数据顺序，UDP不保证   UDP应用场景： 面向数据报方式 网络数据大多为短消息 拥有大量Client 对数据安全性无特殊要求 网络负担非常重，但对响应速度要求高 具体编程时的区别 socket()的参数不同 UDP Server不需要调用listen和accept UDP收发数据用sendto/recvfrom函数 TCP：地址信息在connect/accept时确定 UDP：在sendto/recvfrom函数中每次均 需指定地址信息 UDP：shutdown函数无效 编程区别 通常我们在说到网络编程时默认是指TCP编程，即用前面提到的socket函数创建一个socket用于TCP通讯，函数参数我们通常填为SOCK_STREAM。即socket(PF_INET, SOCK_STREAM, 0)，这表示建立一个socket用于流式网络通讯。 SOCK_STREAM这种的特点是面向连接的，即每次收发数据之前必须通过connect建立连接，也是双向的，即任何一方都可以收发数据，协议本身提供了一些保障机制保证它是可靠的、有序的，即每个包按照发送的顺序到达接收方。…