再也不会用心爱
如何学习分布式系统
有一些系统设计基础的话，给你推荐几本书吧：《面向模式的软件架构 卷4：分布式计算的模式语言》出版社：人民邮电出版社主要讲分布式计算系统软件的设计和实现。
偏软件方向，相对较专业。
《分布式计算（第二版）》出版社：电子工业出版社主要介绍分布式计算的数学基础和理论，揭示设计分布式系统的底层问题（通信、协调、同步及不确定）和基本的算法概念及下界技术。
容易理解，适合自学。
《分布式系统原理与范型》出版社：清华大学出版社全书的第一部分讨论了分布式系统的原理、概念和技术，其中包括通信、进程、命名、同步、一致性和复制、容错以及安全。
第二部分给出了一些实际的分布式系统：基于对象的分布式系统、分布式文件系统、基于文档的分布式系统以及基于协作的分布式系统，介绍了一些实际系统的设计思想和实现技术。
容易理解，适合自学。
什么是软件架构？
当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停。
在软件工程初具规模的时候，软件开发还是以数据结构+算法的形式存在，进入20世纪最后10年，随着面向对象技术、设计模式等在开发过程中的成功应用，软件架构也走进了大家的视野。
软件架构在定义上分为‘组成派’和‘决策派’两大阵营，分别描述如下：'组成派‘认为软件架构是将系统描述成计算组件及组件之间的交互。
它有两个非常明显的特点：关注架构实践的客体——软件，以软件本身作为描述对象。
分析了软件的组成，说明软件不是一个‘原子’意义上的整体，而是有不同的部分经过特定的接口进行连接组成的一个整体，这对软件开发来说很重要。
'决策派'认为软件架构包含了一系列的决策，主要包括：软件系统的组织选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为用于指导这个系统组织的架构风格：这些元素以及它们的接口、协作和组合软件架构并不仅仅关注软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解、经济以及技术的限制和权衡等。
'决策派'有以下两个显著的特点：关注软件架构中的实体——人，以人的决策为描述对象。
归纳了软件架构决策的类型，指出架构决策不仅包括关于软件系统的组织、元素、子系统和架构风格等几类决策，还包括关于众多非功能性需求的决策。
按照‘组成派’的观点，软件架构关注的是软件整体的分割和交互，之所以分割，是因为不同的部分在逻辑或物理上相对独立，通过‘分而治之’的原则进行分割可以更好的理解整个系统，把握用户的需求，但是虽然整个软件可以分割成多个模块或子系统，但是模块和子系统之间的通信和交互也是很重要的，我想按照这种观点，架构师的主要任务是将软件分割成不同的模块，并定义模块之间的接口。
按照‘决策派’的观点，软件是一个在很多限制下产生的产品，这些限制包括用户和技术两方面，用户方面包括功能需求、性能需求、硬件需求等，技术方面包括技术选择、可扩展性、可重用性、可维护性等。
我想按照这中观点，架构师的主要任务就是作出上述个各种限制作出选择或决策。
《软件架构设计》 温昱
cocos2d
前者是游戏框架，后者主要是网络编程，这两者关系不是很大，对于游戏开发了解不是太多，关于服务端的，首先要学好网络编程，最基本的就是socket API，学完这些基本的之后，接下来就是学习用C++开发高性能的并发程序，有很多书籍可以参考，先列出几本：linux多线程服务端编程，面向模式的软件架构卷二（好像是卷二，记不太清楚了），第一本书手把手叫你如何写高并发的服务器程序，后者主要是一些常用的设计模式。
面向服务的应用架构支撑软件有哪些
在做软件架构设计时，根据不同的抽象层次可分为三种不同层次的模式：架构模式（Architectural Pattern）、设计模式（Design Pattern）、代码模式（Coding Pattern）。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。
架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。
这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。
模式的好坏不会影响到系统的总体布局和总体框架。
设计模式定义出子系统或组件的微观结构。
代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。
代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
架构模式（Architectural Pattern）一个架构模式描述软件系统里的基本的结构组织或纲要。
架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
称之为系统模式。
?MVC模式，一个架构模式常常可以分解成很多个设计模式的联合使用。
MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
?Layers（分层）模式，有时也称Tiers模式?Blackboard（黑板）模式?Broker（中介）模式?Distributed Process（分散过程）模式?Microkernel（微核）模式架构模式常常划分成如下的几种：一、 模块结构（From Mud to Structure）型。
帮助架构师将系统合理划分，避免形成一个对象的海洋。
包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
二、分散系统（Distributed Systems）型。
为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。
如Reflection（反射）模式、Microkernel（微核）模式等。
设计模式（Design Pattern）一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。
设计模式在特定的编程语言中实现的时候，常常会用到代码模式。
比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。
代码模式（Coding Pattern）代码模式（或成例）是较低层次的模式，并与编程语言密切相关。
代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等
软件的架构与设计模式之什么是架构
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。
所有的数字都如日历般严谨，风格雄浑。
难以想象这是石器时代的建筑物。
图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。
（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。
与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。
英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。
英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。
丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。
Party这个词的原意就是＂方＂、＂面＂。
政党起源的要害就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。
与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。
最为闻名的，当然就是模式理论和XP理论。
架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。
软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。
软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。
一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。
软件系统必须易于使用。
·市场时机（Time to Market）。
软件用户要面临同业竞争，软件提供商也要面临同业竞争。
以最快的速度争夺市场先机非常重要。
架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。
·物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整...
什么是软件基础架构
软件架构 软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口_（计算机科学）来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。
特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
”[GS93] 但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
