架构之美

jimmy2009 — Thu, 24 May 2012 04:31:00 GMT

之前只要一提起架构，给我一种很深奥、玄妙的感觉，认为很牛X，曾几何，以为软件架构无非就是将几大框架(各层次)整合在一起而已，后来当我从事系分一段时间之后，体会到如果你不能从整体上认识一个系统(软件)的话是没法做架构的，因为满足系统(软件)的功能是一个架构师最起码的要求。从这个层面上讲，那系统分析师与系统架构师一样都要对系统有一个整体的认识，更要认识到该系统在未来可能的变化及做成产品后如何时维护的问题。感觉系统分析师与系统架构师好像没什么区别似的，虽说早就知道一个偏重业务一个偏重技术。
但自我开始阅读“架构之美”这本书后，开始对架构有了进一步的认识：
本质上，架构只是系统设计中的一部分，无非架构更突出某些细节，并通过抽象省略另一些细节。关注实现系统组件的开发者可能不会特别关心所有组件是如何装配在一起，而是主要关注少数组件的设计和开发，包括他们必须遵守的架构约束和可以应用的规则。因此，开发者和架构师面对的是系统设计的不同方面。如果说架构关注的是组件之间的关系和系统组件外部可见的属性，那么设计还要关注这些组件的内部结构。
架构这个词本质上是从建筑学这个行业引申过来的，所以在软件开发这个领域好多概念跟现在的建筑都相似。
项目关注点：
功能性、
可变性、
容量、
生态系统、
模块化、
可构建性、
产品化、
安全性
架构还会影响到组织机构。
架构观点中的常见思想是结构，每种结构都由各种类型的组件及其关系构成：它们如何组合、相互调用、通信、同步，以及进行其他交互。组件可以是建筑中的支架栋梁或故事中的章节或人物。每种结构都是为了帮助架构师理解如何来满足特定的关注点，如可变性或性能。展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足。
架构师的角色：就是做设计上的决定包括行为上和结构上。
信息隐藏结构是面向对象设计方法的基础，它满足的关注点：信息隐藏结构的设计应该能满足可变性、模块化和可构建性的要求。
定义良好的使用结构将创建系统的适当子集，可以用于驱动迭代式或增量式的开发循环，满足的关注点：产品化和生态系统。
信息隐藏模块结构和使用结构是静态的结构，存在于设计时和编码时，进程结构是运行时的结构。
进程结构满足的关注点：性能和容量。
一：伸缩性架构设计
胖客户端与廋客户端
在线游戏环境与企业环境几乎完全相反，
经典的企业环境可以描述为一个“瘦”客户端连接一个“胖”服务器（这个服务器又常常连接到一个更“胖”的数据库服务器）。服务器将保存客户端需要的绝大部分信息，在最理想的情况下，客户端内在不多，没有自已的硬盘，它是服务器的一个称职的显示设备，绝大多数据真正的工作在服务器上完成。
游戏世界特别是大型多人在线游戏（MMO）
MMO和虚拟世界的环境始于一个非常胖的客户端：
它通常是顶级的PC、具有最强劲的CPU、很大的内存，以及本身计算能力很强的显卡。只要有可能，数据就会存放在这些客户端上，特别是那些不会改变的信息，如地理信息、材质贴图和规则集。服务器保持尽可能的简单，通常只保存非常抽象的世界表示和其世界中的实体的表示。而且服务器的设计目标是尽可能少地进行计算。绝大部分的计算留给了客户端。服务器的真正工作是保存共享的世界真实状态，确保不同客户端对世界的看法差异可以根据需要得到纠正。真实状态需要由服务器来保存，因为控制客户端的玩家很有兴趣让他们的表现变成最强，所以可能会受到诱惑，根据他们的喜好修改共享的真实（如查他们可以）。在一般情况下，如果有可能，玩家就会作弊，所以服务器必须是共享真实的最终来源。
MMO和虚拟世界的数据访问模式也和企业中看到的情有着很大的区别。企业中的一般经验法则是90%的数据访问都是只读的，大多数任务会读取大量数据，然后会再改写少量数据。在MMO和虚拟世界的环境中，大多数任务只访问服务器上少量的状态数据，但在它们访问的数据中，大约一半会被改写
在线游戏环境与企业环境的共同关注点：
1，延迟是敌人，但也有不同。最大的不同要追溯到用户所做的事情的不同。在企业环境中，目标是管理业务，如果总吞吐量得到改进，在处理中有一点延迟是可以接受的，在MMO和虚拟世界的环境中，目标是开心，而延迟是开心的敌人，所以MMO或虚拟世界的基础设施需要围绕着尽可能限定延迟的需求来设计即便以吞吐量为代价也在所不惜。
XX在线游戏（Darkstar）架构的目标：
1，对伸缩性的需求表明，系统应该是分布式的、并发的，游戏程序员应该把系统视为一台单机，运行着一个线程，所有允许部署到多线程和多
计算机上的机制都应由XX在线游戏的基础设施来考虑。
2，支持随时伸缩，同时不要求游戏逻辑受到伸缩的影响，这个架构应该支持游戏动态地响应负载，而不是让这种响应成为游戏设计的工作的一部分。
架构：
Darkstar由一组独立的服务构成，用一组相互联系的服务来构建系统，“分而治之”，分而治之是设计所有大型计算机系统的基本方法。
客户端连接到游戏逻辑使用的通信机制是基础设施的一部分，这些机制支持客户端到服务器的直接通信，也支持一种“发布-订阅”通道，任何发往通道的消息都会送达该通道的所有订阅者。
游戏服务器的设计方式和游戏为为支持并玩家所采取的伸缩性技术。
并行与延迟

二：数据增长——Facebook平台的架构

jimmy2009 2012-05-24 12:31 发表评论

RESTlet学习笔记

jimmy2009 — Thu, 24 May 2012 04:19:00 GMT

这两天学习REST及其java实现框架Restlet.

具象状态传输（Representational state transfer，REST）是设计基于命名资源而非消息的松耦合应用程序的一种风格。构建 RESTful 应用程序的最困难的部分在于确定要公开哪些资源.个人认为它跟DDD联系的很紧密，特别是REST中的“资源”，我个人理解它就是从领域模型中的模型而来的。
我们先来看一下restlet core api吧：

Overview of a Restlet architecture

Here is a diagram illustrating how the API composes components, connectors, virtual host and applications. Applications are in turncomposed of resources.

用白说来讲就是：Application通过Router 将某个URI与Resource绑定在一定，而一个componet可能含有多个Application,
还有Representation 这个类其实也很重要。Representation entity：Restlet中全部的接受和返回对象都Representation类的子类。
如在WEB APP中经常需要从一个FORM中拿到其Representation(getWebRepresentation() )或组装成一个Representation Form(Representation webForm) ,以便客户端与服务器进行交互。我们知道REST是以资源为中心的，一个URI就代表了对这个资源的CURD操作。@Path这个注解提明了
哪个操作是由该资源的那个方法来实现的如:
@POST
@Path("add")
public String addStudent(Representation entity) {
}
...
@DELETE
@Path("delete/{id}")
public String deleteStudent(@PathParam("id") int id) {
int status = ResourceHelper.deleteStudent(id);
return String.valueOf(status);
}
representation package overriew:
Restlet 对表现层的技术支持也就是通来representation这个类来实现的，representation
Restlet并没有你Setvlet API那样有自已的JSP作表现的技术，它是通过将这三种模板技术整合起来而已如 : XSLT, FreeMarker and Apache Velocity
The org.restlet.representation package contains common representation data elements. Here is a hierarchy diagram with the core Representation classes:

Overview Representation package

当然restlve只是提供了一个入口，碰到要对数据库进行CURD操作时，基具体实现还是由JDBC等技术来实现.

jimmy2009 2012-05-24 12:19 发表评论

BlogJava-JimmyJin-随笔分类-系统架构

架构之美

RESTlet学习笔记

Overview of a Restlet architecture

Overview Representation package