1、OpenStack 的架构1. OpenStack 是什么OpenStack 既是一个社区，也是一个项目和一个开源软件，它提供了一个部署云的操作平台或工具集。其宗旨在于，帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。OpenStack 旗下包含了一组由社区维护的开源项目，他们分别是 OpenStack Compute（Nova ） ，OpenStack Object Storage（Swift） ，以及 OpenStack Image Service（Glance） 。OpenStack Compute1，为云组织的控制器，它提供一个工具来部
2、署云，包括运行实例、管理网络以及控制用户和其他项目对云的访问（the cloud through users and projects） 。它底层的开源项目名称是 Nova，其提供的软件能控制 IaaS 云计算平台，类似于 Amazon EC2和 Rackspace Cloud Servers。实际上它定义的是，与运行在主机操作系统上潜在的虚拟化机制交互的驱动，暴露基于 Web API 的功能。OpenStack Object Storage2，是一个可扩展的对象存储系统。对象存储支持多种应用，比如复制和存档数据，图像或视频服务，存储次级静态数据，开发数据存储整合的新应用，存储容量难以估计的数
3、据，为 Web 应用创建基于云的弹性存储。OpenStack Image Service1，是一个虚拟机镜像的存储、查询和检索系统，服务包括的RESTful API 允许用户通过 HTTP 请求查询 VM 镜像元数据，以及检索实际的镜像。 VM镜像有四种配置方式：简单的文件系统，类似 OpenStack Object Storage 的对象存储系统，直接用 Amazons Simple Storage Solution (S3) 存储，用带有 Object Store 的 S3 间接访问S3。三个项目的基本关系如下图 1-1 所示：1-1 OpenStack 三个组件的关系2. 云服务提供商的
4、概念架构OpenStack 能帮我们建立自己的 IaaS，提供类似 Amazon Web Service 的服务给客户。为实现这一点，我们需要提供几个高级特性：a) 允许应用拥有者注册云服务，查看运用和计费情况；b) 允许 Developers/DevOps folks 创建和存储他们应用的自定义镜像；c) 允许他们启动、监控和终止实例；d) 允许 Cloud Operator 配置和操作基础架构这四点都直击提供 IaaS 的核心，现在假设你同意了这四个特性，现在就可以将它们放进如下所示的概念架构 2-1 中。2-1 OpenStack 概念架构在此模型中，作者假设了需要与云交互的四个用户集：
5、developers, devops, owners and operators，并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法（presentation, logic and resources） ，它带有两个正交区域。展示层，组件与用户交互，接受和呈现信息。Web portals 为非开发者提供图形界面，为开发者提供 API 端点。如果是更复杂的结构，负载均衡，控制代理，安全和名称服务也都会在这层。逻辑层为云提供逻辑（intelligence）和控制功能。这层包括部署（复杂任务的工作流） ，调度（作业到资源的映射） ，策略（配额等等） ，镜像注册 image regi
6、stry (实例镜像的元数据)，日志 (事件和计量) 。假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系统。在任何复杂的环境下，我们都将需要一个 management 层来操作这个环境。它应该包括一个 API 访问云管理特性以及一些监控形式（forms） 。很可能，监控功能将以整合的形式加入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了monitoring 和 admin API，在更完全的架构中，你将见到一系列的支持功能，比如provisioning 和 configuration management。最后，资源层。既然这是一个 compute
7、云，我们就需要实际的 compute、network 和 storage 资源，以供应给我们的客户。该层提供这些服务，无论他们是服务器，网络交换机，NAS（network attached storage）还是其他的一些资源。3. OpenStack Compute 架构3.1 OpenStack Compute 逻辑架构OpenStack Compute 逻辑架构中，组件中的绝大多数可分为两种自定义编写的 Python守护进程（custom written python daemons） 。a) 接收和协调 API 调用的 WSGI 应用（nova-api, glance-api, etc）
8、b) 执行部署任务的 Worker 守护进程（nova-compute, nova-network, nova-schedule, etc.）然而，逻辑架构中有两个重要的部分，既不是自定义编写，也不是基于 Python，它们是消息队列和数据库。二者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。逻辑架构图 3-1 如下所示：3-1 OpenStack Compute 逻辑架构从图中，我们可以总结出三点：a) 终端用户（DevOps, Developers 和其他的 OpenStack 组件）通过和 nova-api 对话来与 OpenStack Compute 交互。b) OpenS
9、tack Compute 守护进程之间通过队列（行为）和数据库（信息）来交换信息，以执行 API 请求。c) OpenStack Glance 基本上是独立的基础架构，OpenStack Compute 通过 Glance API来和它交互。其各个组件的情况如下：a) nova-api 守护进程是 OpenStack Compute 的中心。它为所有 API 查询（OpenStack API 或 EC2 API）提供端点，初始化绝大多数部署活动（比如运行实例） ，以及实施一些策略（绝大多数的配额检查） 。b) nova-compute 进程主要是一个创建和终止虚拟机实例的 Worker 守护进
10、程。其过程相当复杂，但是基本原理很简单：从队列中接收行为，然后在更新数据库的状态时，执行一系列的系统命令执行他们。c) nova-volume 管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商，比如，ISCSI 和 AoE。d) Nova-network worker 守护进程类似于 nova-compute 和 nova-volume。它从队列中接收网络任务，然后执行任务以操控网络，比如创建 bridging interfaces 或改变iptables rules。e) Queue 提供中心 hub，为守护进程传递消息。当前用 RabbitMQ 实现。但是理论上能是 p
11、ython ampqlib 支持的任何 AMPQ 消息队列。f) SQL database 存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型，在用的实例，可用的网络和项目。理论上，OpenStack Compute 能支持 SQL-Alchemy 支持的任何数据库，但是当前广泛使用的数据库是 sqlite3（仅适合测试和开发工作） ，MySQL 和 PostgreSQL。g) OpenStack Glance，是一个单独的项目，它是一个 compute 架构中可选的部分，分为三个部分：glance-api, glance-registry and the image sto
12、re. 其中，glance-api 接受API 调用，glance-registry 负责存储和检索镜像的元数据，实际的 Image Blob 存储在 Image Store 中。Image Store 可以是多种不同的 Object Store，包括 OpenStack Object Storage (Swift)h) 最后，user dashboard 是另一个可选的项目。OpenStack Dashboard 提供了一个OpenStack Compute 界面来给应用开发者和 devops staff 类似 API 的功能。当前它是作为 Django web Application 来实
13、现的。当然，也有其他可用的 Web 前端。3.2 概念映射将逻辑架构映射到概念架构中（如 3-2 所示） ，可以看见我们还缺少什么。3-2 逻辑架构到概念架构的映射这种覆盖方式并不是唯一的，这里的只是作者的理解。通过覆盖 OpenStack Compute 逻辑组件，Glance 和 Dashboard，来表示功能范围。对于每一个覆盖，都有相应的提供该功能的逻辑组件的名称。a) 在这种覆盖范围中，最大的差距是 logging 和 billing。此刻，OpenStack Compute 没有能协调 logging 事件、记录日志以及创建/呈现 bills 的 Billing 组件。真正的焦点是
14、 logging 和 Billing 的整合。这能通过以下方式来补救。比如代码扩充，商业产品或者服务或者自定义日志解析的整合。b) Identity 也是未来可能要补充的一点。c) customer portal 也是一个整合点。user dashboard（见运行的实例，启动新的实例）没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据（lodge trouble tickets） 。而且，这很可能对我们设想的服务提供商来说是合适的。d) 理想的情况是，Admin API 会复制我们能通过命令行接口做的所有功能。在带有Admin API work 的 Diablo
15、发布中会更好。e) 云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前，OpenStack Compute 提供 nova-instancemonitor，它跟踪计算结点使用情况。未来我们还需要三方工具来监控。f) Policy 是极其重要的方面，但是会与供应商很相关。从 quotas 到 QoS，到隐私控制都在其管辖内。当前图上有部分覆盖，但是这取决于供应商的复杂需求。为准确起见，OpenStack Compute 为实例，浮点 IP 地址以及元数据提供配额。g) 当前，OpenStack Compute 内的 Scheduling 对于大的安装来说是相当初步的。调度器是
16、以插件的方式设计的，目前支持 chance(随机主机分配)，simple(最少负载)和zone（在一个可用区域里的随机结点。 ）分布式的调度器和理解异构主机的调度器正在开发之中。如你所见，OpenStack Compute 为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。3.3 OpenStack Compute 系统架构OpenStack Compute 由一些主要组件组成。 “Cloud controller”包含很多组件，它表示全局状态，以及与其他组件交互。实际上，它提供的是 Nova-api 服务。它的功能是：为所有 API 查询提供一个端点，初始化绝大多数
17、的部署活动，以及实施一些策略。API 服务器起 cloud controller web Service 前端的作用。Compute controller 提供 compute 服务资源，典型包含 compute service，Object Store component 可选地提供存储服务。 Auth manager 提供认证和授权服务，Volume controller 为 compute servers 提供快速和持久的块级别存储。Network controller 提供虚拟网络使 compute servers 彼此交互以及与公网进行交互。Scheduler 选择最合适的 comp
18、ute controller 来管理（host）一个实例。OpenStack Compute 建立在无共享、基于消息的架构上。Cloud controller 通过 HTTP与 internal object store 交互，通过 AMQP 和 scheduler、network controller、 和 volume controller 来进行通信。为了避免在等待接收时阻塞每个组件，OpenStack Compute 用异步调用的方式。为了获得带有一个组件多个备份的无共享属性，OpenStack Compute 将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储
19、中，必要时用质子事务。对系统状态的请求会从 store 中读出。在少数情况下，控制器也会短时间缓存读取结果。3.4 OpenStack Compute 物理架构OpenStack Compute 采用无共享、基于消息的架构，非常灵活，我们能安装每个 nova- service 在单独的服务器上，这意味着安装 OpenStack Compute 有多种可能的方法。可能多结点部署唯一的联合依赖性，是 Dashboard 必须被安装在 nova-api 服务器。几种部署架构如下：a) 单结点：一台服务器运行所有的 nova- services，同时也驱动虚拟实例。这种配置只为尝试 OpenStack
20、 Compute，或者为了开发目的；b) 双结点：一个 cloud controller 结点运行除 nova-compute 外的所有 nova-services，compute 结点运行 nova-compute。一台客户计算机很可能需要打包镜像，以及和服务器进行交互，但是并不是必要的。这种配置主要用于概念和开发环境的证明。c) 多结点：通过简单部署 nova-compute 在一台额外的服务器以及拷贝 nova.conf 文件到这个新增的结点，你能在两结点的基础上，添加更多的 compute 结点，形成多结点部署。在较为复杂的多结点部署中，还能增加一个 volume controller
21、 和一个 network controller 作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例，至少是 4个结点是最好的。一个可能的 Openstack Compute 多服务器部署（集群中联网的虚拟服务器可能会改变）如下 3-3 所示：3-3 OpenStack Compute 物理架构一如果你注意到消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging 服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的 RabbitMQ 服务器。部署中可以在任意服务器上运行任意 nova-service，只要 nova.conf中配置为指向 Rabb
22、itMQ 服务器，并且这些服务器能发送消息到它。下图 3-4 是另外一种多结点的部署架构。3-4 多结点的部署架构二3.5 OpenStack Compute 服务架构因为 Compute 有多个服务，也可能有多种配置，下图 3-5 显示了总体的服务架构，以及服务之间的通信系统。3-5 OpenStack Compute 服务架构4. OpenStack Image ServiceOpenStack Image Service 包括两个主要的部分，分别是 API server 和 Registry server(s)。OpenStack Image Service 的设计，尽可能适合各种后端仓
23、储和注册数据库方案。API Server（运行“glance api”程序）起通信 hub 的作用。比如各种各样的客户程序，镜像元数据的注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service 就是通过这些机制来实际保存进来的虚拟机镜像的。OpenStack Image Service 支持的后端仓储有：a) OpenStack Object Storage。它是 OpenStack 中高可用的对象存储项目。b) FileSystem。OpenStack Image Se
24、rvice 存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。c) S3。该后端允许 OpenStack Image Service 存储虚拟机镜像在 Amazon S3 服务中。d) HTTP。OpenStack Image Service 能通过 HTTP 在 Internet 上读取可用的虚拟机镜像。这种存储方式是只读的。OpenStack Image Service registry servers 是遵守 OpenStack Image Service Registry API的服务器。根据安装手册，这两个服务安装在同一个服务器上。镜像本身则可存储在
25、 OpenStack Object Storage， Amazons S3 infrastructure，fileSystem。如果你只需要只读访问，可以存储在一台 Web 服务器上。5. OpenStack Object Storage5.1 关键概念a) Accounts 和 Account ServersOpenStack Object Storage 系统被设计来供许多不同的存储消费者或客户使用。每个用户必须通过认证系统来识别自己。为此，OpenStack Object Storage 提供了一个授权系统（swauth ） 。运行 Account 服务的结点与个体账户是不同的概念。Ac
26、count 服务器是存储系统的部分，必须和 Container 服务器和 Object 服务器配置在一起。b) Authentication 和 Access Permissions你必须通过认证服务来认证，以接收 OpenStack Object Storage 连接参数和认证令牌。令牌必须为所有后面的 container/object 操作而传递。典型的，特定语言的 API 处理认证，令牌传递和 HTTPS request/response 通信。通过运用 X-Container-Read: accountname 和 X-Container-Write: accountname:user
27、name，你能为用户或者账户对对象执行访问控制。比如，这个设置就允许来自 accountname 账户的的任意用户来读，但是只允许 accountname 账户里的用户username 来写。你也能给 OpenStack Object Storage 中存储的对象授予公共访问的权限，而且可以通过 Referer 头部阻止像热链接这种基于站点的内容盗窃，来限制公共访问。公共的container 设置被用作访问控制列表之上的默认授权。比如，X-Container-Read: referer: any 这个设置，允许任何人能从 container 中读，而不管其他的授权设置。一般来说，每个用户能完全
28、访问自己的存储账户。用户必须用他们的证书来认证，一旦被认证，他们就能创建或删除 container，以及账户之类的对象。一个用户能访问另一个账户的内容的唯一方式是，他们享有一个 API 访问 key 或你的认证系统提供的会话令牌。c) Containers and Objects一个 Container 是一个存储隔间，为你提供一种组织属于属于你的数据的方式。它比较类似于文件夹或目录。Container 和其他文件系统概念的主要差异是 containers 不能嵌套。然而，你可以在你的账户内创建无数的 containers。但是你必须在你的账户上有一个container，因为数据必须存在 Co
29、ntainer 中。Container 取名上的限制是，它们不能包含“/” ，而且长度上少于 256 字节。长度的限制也适用于经过 URL 编码后的名字。比如，Course Docs 的 Container 名经过 URL 编码后是“Course%20Docs” ，因此此时的长度是 13 字节而非 11 字节。一个对象是基本的存储实体，和表示你存储在 OpenStack Object Storage 系统中文件的任何可选的元数据。当你上传数据到 OpenStack Object Storage，它原样存储，由一个位置（container） ，对象名，以及 key/value 对组成的任何元数据
30、。比如，你可选择存储你数字照片的副本，把它们组织为一个影集。在这种情况下，每个对象可以用元数据 Album :Caribbean Cruise 或 Album : Aspen Ski Trip 来标记。对象名上唯一的限制是，在经过 URL 编码后，它们的长度要少于 1024 个字节。上传的存储对象的允许的最大大小 5GB，最小是 0 字节。你能用内嵌的大对象支持和St 工具来检索 5GB 以上的对象。对于元数据，每个对象不应该超过 90 个 key/value 对，所有 key/value 对的总字节长度不应该超过 4KB。d) OperationsOperations 是你在 OpenSta
31、ck Object Storage 系统上执行的行为，比如创建或删除containers，上传或下载 objects 等等。Operations 的完全清单可以在开发文档上找到。Operations 能通过 ReST web service API 或特定语言的 API 来执行。值得强调的是，所有操作必须包括一个来自你授权系统的有效的授权令牌。e) 特定语言的 API 绑定一些流行语言支持的 API 绑定，在 RackSpace 云文件产品中是可用的。这些绑定在基础 ReST API 上提供了一层抽象，允许变成人员直接与 container 和 object 模型打交道，而不是 HTTP 请求
32、和响应。这些绑定可免费下载，使用和修改。它们遵循 MIT 许可协议。对于 OpenStack Object Storage，当前支持的 API 绑定是： PHP，Python，Java ，C#/.NET 和Ruby。5.2 Object Storage 如何工作 a) RingRing 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects 都有单独的 Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring 进行交互以确定它在集群中的位置。Ring 用 zones，devices，partitions，和 repl
33、icas 来维护映射，在 Ring 中的每个分区都会在集群中默认有三个副本。分区的位置存储在 Ring 维护的映射中。 Ring 也负责确定失败场景中接替的设备。 （这点类似 HDFS 副本的复制） 。分区的副本要保证存储在不同的zone。Ring 的分区分布在 OpenStack Object Storage installation 所有设备中。分区需要移动的时候，Ring 确保一次移动最少的分区，一次仅有一个分区的副本被移动。权重能用来平衡分区在磁盘驱动上的分布。Ring 在代理服务器和一些背景进程中使用。b) Proxy Server代理服务器负责将 OpenStack Object
34、Storage 架构中其他部分结合在一起。对于每次请求，它都查询在 Ring 中查询 account, container, or object 的位置，并以此转发请求。公有APIs 也是通过代理服务器来暴露的。大量的失败也是由代理服务器来进行处理。比如一个服务器不可用，它就会要求 Ring来为它找下一个接替的服务器，并把请求转发到那里。当对象流进或流出 object server 时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。Proxy 服务器的功能可以总结为：查询位置，处理失败，中转对象。c) Object ServerObject Server，是非常
35、简单的 blob 存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。对象以源于对象名的 hash 和操作的时间戳的路径来存放。上一次写总会成功，确保最新的版本将被使用。删除也视作文件的一个版本：这确保删除的文件也被正确复制，更旧的把本不会因为失败情形离奇消失。d) Container Server其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。列表被存储为 sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及 container 中使用的总存储量。
36、e) Account Server它是类似于 Container Server，除了它是负责 containers 的列表而非对象。f) Replication设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个 Hash 列表来快速比较每个分区的片段，而 containe 和 account replication 用的是 Hash 和共享的高水印结合的方法。副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到 Peer。Account和 container repl
37、ication 通过 HTTP or rsync 把整个数据库文件推送遗失的记录。副本也通过 tombstone 设置最新版本的方式，确保数据从系统中清除。g) 更新器（Updaters）有时，container 或 account 数据不能被立即更新，这通常是发生在失败的情形或高负载时期。如果一个更新失败，该更新会在文件系统上本地排队，更新器将处理这些失败的更新。事件一致性窗口（eventual consistency window）最可能来起作用。比如，假设一个container 服务器正处于载入之中，一个新对象正被放进系统，代理服务器一响应客户端成功，该对象就立即可读了。然而，conta
38、iner 服务器没有更新 Object 列表，所以更新就进入队列，以等待稍后的更新。Container 列表，因此可能还不会立即包含这个对象。实际上，一致性窗口只是与 updater 运行的频率一样大，当代理服务器将转发清单请求到响应的第一个 container 服务器中，也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。h) AuditorsAuditors 会检查 objects, containers, 和 accounts 的完整性。如果发先损坏的文件，它将被隔离，好的副本将会取代这个坏的文件。如果发现其他的错误，它们会记入
39、到日志中。5.3 OpenStack Object Storage 物理架构 Proxy Services 偏向于 CPU 和 network I/O 密集型，而 Object Services， Container Services， Account Services 偏向于 disk and networkI/O 密集型。可以在每一服务器上安装所有的服务，在 Rackspace 内部， 他们将 Proxy Services 放在他们自己的服务器上，而所有存储服务则放在同一服务器上。这允许我们发送 10G 的网络给代理，1G 给存储服务器，从而保持对代理服务器的负载平衡更好管理。我们能通过增
40、加更多代理来扩展整个 API 吞吐量。如果需要获得 Account 或 Container Services 更大的吞吐量，它们也可以部署到自己的服务器上。在部署 OpenStack Object Storage 时，可以单结点安装，但是它只适用于开发和测试目的。也可以多服务器的安装，它能获得分布式对象存储系统需要的高可用性和冗余。有这样一个样本部署架构，如图 5-1 所示。一个 Proxy 结点，运行代理服务，一个 Auth 结点，运行认证服务，五个 Storage 结点，运行 Account， Container 和 Object 服务。5-1 五个 Storage 结点的 OpenSta
41、ck Object Storage 物理架构参考文献1 OpenStack Compute Administration Manual.http:/docs.openstack.org/cactus/openstack-compute/admin/content.2 OpenStack Object Storage Developer Guide.http:/docs.openstack.org/.人生就像一部书，每个人都在书写着自己的故事，书写着生命中曾承载的苦辣酸甜和正在经历的风霜雪雨。不管这部书的情节精彩也好，简约也罢，我们都必须字斟句酌，用心构思。只有这样，认真写好人生的每一个章节，才
42、能把握生命的主旋律。人生也像一条河，有谁不是在风里行舟，雨中穿梭。昨天还在逆浪而行，今朝依然奔奔波波。尽管如此，我们也不应气馁，更不敢稍有停歇。只有这样，才能穿越人生的风浪，踏平生命的坎坷，从而抵达理想的彼岸，收获人生累累硕果。人生还像一盘棋，我们每个人俨如上帝手中的一枚棋子，贫富贵贱难预料，生老病死不由己。楚河汉界今犹在，谁见君王卷土来？是啊！人生苦短，岁月蹉跎。在不老的时光里，我们每个人充其量不过是一个匆匆的过客。当你走过半生，蓦然首，你会发觉：转眼间，我们便告别了葱茏的年华，跨过了中年的门槛，走进了枫红菊艳的时节。有道是，流光容易把人抛，红了樱桃，绿了芭蕉。岁月如梭，不经意间便穿越半生沧
43、桑。回首往事，多少情怀已经更改，多少青春早已不再，多少梦想恍如云烟，多少足迹已湮入尘埃。实乃，人生得失如萍散，雪落花开辞红颜。三毛说：“我来不及认真地年轻，待明白过来时，只能选择认真地老去。”昨天已经落幕，明天无法彩排，唯有今天才是人生的最好舞台。轻捻指尖流年，细数过往云烟。曾经的莽撞少年，总以为伸手就能够着天，凡理都要辩出个曲和直，凡事都要弄出个里和面。人过中年，我们才恍然顿悟：不和别人比，好好活自己，这才是后半场人生棋盘最好的布局。好好活自己，就要力求“身心两安逸”.老了不可怕，就怕放不下。人过中年，身体机能不断下降，就像一部半新不旧的机器，各个零部件都已濒临保养期，如果不及时加以检修，等
44、到停止工作那一天，悔之晚矣。凡事不攀比，保命是正理，浮云随风去，任尔东与西。身体健康是前提，心情快乐才安逸。服老不并非消及，而是保护自己。山有山的伟岸，水有水的柔情，每个人的生活模式千差万别，就像世界上没有一模一样的两片叶子，你有你的脉络，我有我的纹理。寸有所长，尺有所短，每个人都不是完美无缺的个体，你有你的色彩，我有我的艳丽；你羡慕别人的同时，别人也许正在羡慕你。就像卞之琳所说的那样，你站在桥上看风景，看风景的人在楼上看你。明月装饰了你的窗子，你装饰了别人的梦。我们每个人何尝不是一道独一无二的风景线，只是缺乏一双欣赏的眼光而已。好好活自己，就要力求“退而求其次”.后半生，我们没有多余的精力去
45、开拓一个未知的领域。所谓的 “大不了从头再来 ”,那只不过是年轻人的豪言壮语。人生后半场，上帝给予我们的时间和精力是有限的，适时地放手才是最好的选择。退而求其次，看似是一种“无奈”,却也是一种豁达的智慧。它并非真正意义上的 “退化”, 而是为生命“留白”,为自己留下一点周旋的余地。老子曾言，“虚而不屈动而愈出，多言数穷不如守中。”事多必乱，言多必失，只有保留一定的“空”,才能其用无穷。正所谓，月满则亏，水满则溢。有时退一步海阔天空，进一步山重水复。留白，也是一种取舍，只有“丢卒保车”,才能满盘皆活。古人说：“路漫漫其修远兮，吾将上下而求索。”可见，“求索”原本就分“上”“下”.当你的“上策”无
46、法策马扬鞭时，你必须要退避三舍求 “下策”, 谋定而后动，知止而有得。叶公好龙，玩假把式；夜郎自大，唯我独尊，只能是自讨苦吃。好好活自己，就要力求营造一个“小天地”.人生需自渡，这个世界上从来就没有救世主。自己的人生，黯淡与精彩完全由自己去书写，去掌舵，去布局。红尘如梦，亦真亦幻；人生如戏，亦悲亦喜。当曲终人散时，不过是乐者自乐，歌者自歌；伤者自伤，痛者自痛。人生就像一部书，每个人都在书写着自己的故事，书写着生命中曾承载的苦辣酸甜和正在经历的风霜雪雨。不管这部书的情节精彩也好，简约也罢，我们都必须字斟句酌，用心构思。只有这样，认真写好人生的每一个章节，才能把握生命的主旋律。人生也像一条河，有谁
47、不是在风里行舟，雨中穿梭。昨天还在逆浪而行，今朝依然奔奔波波。尽管如此，我们也不应气馁，更不敢稍有停歇。只有这样，才能穿越人生的风浪，踏平生命的坎坷，从而抵达理想的彼岸，收获人生累累硕果。人生还像一盘棋，我们每个人俨如上帝手中的一枚棋子，贫富贵贱难预料，生老病死不由己。楚河汉界今犹在，谁见君王卷土来？是啊！人生苦短，岁月蹉跎。在不老的时光里，我们每个人充其量不过是一个匆匆的过客。当你走过半生，蓦然首，你会发觉：转眼间，我们便告别了葱茏的年华，跨过了中年的门槛，走进了枫红菊艳的时节。有道是，流光容易把人抛，红了樱桃，绿了芭蕉。岁月如梭，不经意间便穿越半生沧桑。回首往事，多少情怀已经更改，多少青春
48、早已不再，多少梦想恍如云烟，多少足迹已湮入尘埃。实乃，人生得失如萍散，雪落花开辞红颜。三毛说：“我来不及认真地年轻，待明白过来时，只能选择认真地老去。”昨天已经落幕，明天无法彩排，唯有今天才是人生的最好舞台。轻捻指尖流年，细数过往云烟。曾经的莽撞少年，总以为伸手就能够着天，凡理都要辩出个曲和直，凡事都要弄出个里和面。人过中年，我们才恍然顿悟：不和别人比，好好活自己，这才是后半场人生棋盘最好的布局。好好活自己，就要力求“身心两安逸”.老了不可怕，就怕放不下。人过中年，身体机能不断下降，就像一部半新不旧的机器，各个零部件都已濒临保养期，如果不及时加以检修，等到停止工作那一天，悔之晚矣。凡事不攀比，
49、保命是正理，浮云随风去，任尔东与西。身体健康是前提，心情快乐才安逸。服老不并非消及，而是保护自己。山有山的伟岸，水有水的柔情，每个人的生活模式千差万别，就像世界上没有一模一样的两片叶子，你有你的脉络，我有我的纹理。寸有所长，尺有所短，每个人都不是完美无缺的个体，你有你的色彩，我有我的艳丽；你羡慕别人的同时，别人也许正在羡慕你。就像卞之琳所说的那样，你站在桥上看风景，看风景的人在楼上看你。明月装饰了你的窗子，你装饰了别人的梦。我们每个人何尝不是一道独一无二的风景线，只是缺乏一双欣赏的眼光而已。好好活自己，就要力求“退而求其次”.后半生，我们没有多余的精力去开拓一个未知的领域。所谓的 “大不了从头再来 ”,那只不过是年轻人的豪言壮语。人生后半场，上帝给予我们的时间和精力是有限的，适时地放手才是最好的选择。退而求其次，看似是一种“无奈”,却也是一种豁达的智慧。它并非真正意义上的 “退化”, 而是为生命“留白”,为自己留下一点周旋的余地。老子曾言，“虚而不屈动而愈出，多言数穷不如守中。”事多必乱，言多必失，只有保留一定的“空”,才能其用无穷。正所谓，月满则亏，水满则溢。有时退一步海阔天空，进一步山重水复。留白，也是一种取舍，只有“丢卒保车”,才能满盘皆活。古人说：“路漫漫其修远兮，吾将上下而求索。”可见，“求索”原本就分“上”“下”.当你的“上策”无法策马扬鞭时
