#
一、什么是架构
架构就是系统的结构，是一种机制。
架构就是系统的结构。你建立架构来解释将来系统的结构和这种结构如何支撑业务需求和非功能需求。你可以定义这种结构作为一种机制，系统如何用来解决一些普遍问题。这个机制有能力以统一的方式支持业务需求。例如，持久化机制必须被系统统一使用，这意味着，任何时候系统如果要做持久化，必须以同样的方式。将持久化机制定义后，你就提供了一种默认的所有设计人员必须遵循的方式。这些架构体制，如持久化、分布式、通讯、交易管理和安全就是你建立系统的基础，而且必须得建立的。
什么是建立架构呢？就是你建立的符合系统中规定的非功能需求的基础。例如，系统中说明对用户的反应时间不能超过3秒，你建立的软件基础就必须符合这个需求。这同时也意味着你已经给设计人员一个允许他们设计和编码来建立系统时而不必担心这些非功能需求。一个关于架构中比较真实的问题是：架构的建立什么时候停止，设计流程什么时候开始？对于每个系统没有最终答案。这个架构和设计的问题可以被总结起来和控制。架构定义了将会建立什么，设计了你怎样建立系统的外框。一个或少数人关注全景来控制架构的流程，其他多数人关注如何实现全景是设计所要控制的。架构师设计架构，设计团队在这个架构中用它来达成系统的全部目标。因此，如果你正在为有经验的设计人员建立架构，你就不必象为缺少经验的设计人员那样提供尽可能详尽的文档。
当你在建立架构来没跟系统的非功能需求时你通常不会有无限制的资金来购买硬件、软件和开发资源，因此你必须使系统能在有限的预算中很好的运行。例如，当你只有一台电脑来支撑内部用户时，你怎样建立可拓展的系统来满足互联网时代？没有资金来购买软件产品时，你怎样建立架构？这些就是架构师们建立系统架构时面对的问题的例子。你会面临很多困难的选择，和做很多取舍来解决这类问题。由于你作了取舍，很重要的是取舍你必须用文档说明，使得开发人员能够理解为什么要作这个取舍，这样你就不会收到来自开发人员的问题了。如果你决定使用ORACLE在系统中，你就必须用文档注明为什么要选择ORACLE而不选其他数据库。你建立架构时的取舍关注非功能需求。大多数系统没有足够的资金来满足所有的非功能性需求。作为架构师，你就必须平衡非功能需求和预算之间的矛盾。如果要做24*7的高可用光是购买硬件花掉了你全部的预算，那就是说没有多余的钱来购买应用服务器来维护非功能需求了，你就必须调整你的软件架构了。调整依赖于你正在建立架构的系统和与投资人的关系。
二、架构师角色
架构师必须具有以下特点。
架构师必须是一个全面的，成熟的，有经验的，受过教育的，学习迅速的，一个领导者，很好的沟通，和在必须时候作出困难的决定。全面的是指，架构师必须具有业务和问题领域的工作知识。他们能够通过经验和教育获取这些知识。另外架构师也必须具有广阔的技术知识。一个好的架构师能够评估所有可能的方案不管使用何种技术。
架构师要做些什么？架构师与资深开发人员有什么不同？这些都是一些常问的问题。设计师考虑一个用户按下一个按钮时将会发生什么，架构师则考虑成行千上万的用户按下一个按钮时将会发生什么。架构师要减轻和系统相关的风险。技术风险可能是未知的、未证明的或未测试的。风险来自非功能需求，有时也可能来自业务需求。不管哪种风险，都很容易地尽早地在建立架构阶段指出这个风险。
架构师必须领导开发团队保证设计师的开发人员根据这个架构一构建系统。关于取舍必须作出困难的决定，作为领导者，就是作决定的人。为了领导项目团队，架构师必须是一个好的沟通者，包括读和写。通常是通过虚拟模型和群组讨论。如果架构师不能很好的沟通，设计师和开发人员也许不能正确地构建系统。
这个适合大数据量的分布式的企业环境。
Lily以NoSQL技术为主题，是建立在云计算上的内容仓库(content repository)。
它是基于Apache的
HBase(存储)和
Solr(索引/搜索)，并提供了大型内容集合存储与检索的解决方案。
可运用在门户网站，内容管理系统，及时搜索，档案应用，文案管理，等等。
从ITEYE上看到的，郁闷的是找不到发贴人了
从 ITeye论坛最新讨论
1.Web - Application Developer
Must to have:
熟悉Java 开发，有3-4年Java Web开发经验
熟悉常用J2EE规范，JSP， Servlet，JDBC
熟悉SQL，能熟练写常用SQL script，了解常用的SQL性能优化
熟悉常用的开源框架，Spring，Spring MVC or Struts2, OR-Maping (Hibernate, iBatis, JPA)
Nice to have:
熟悉Web Service，Hessian 等常用的远程交互协议
熟悉Ajax等Web 2.0技术, JavaScript框架 （jQuery/Dojo）
熟悉常用的设计模式，能识别代码中的设计模式
熟悉Junit testNG 等单元测试框架
熟悉WAS, Tomcat, JBoss等应用服务器
熟悉SVN, CVS等代码管理工具
有使用Maven，Ant的经验
有电商经验者优先
--------------------------------------------------------
2. Web - Application Developer: e-Commerce
熟悉Java 开发, 3-4年工作经验，熟悉jquery, EXTJS，能对页面进行调试，了解各种调试工具，如：firebug，firecookies，yslow，pagespeed
对jquery plugin有一定研究，最好自己开发过插件，有自己开发js框架经验
对开源框架有深入研究，比如SSH（Spring，Struts，Hibernate等）
熟悉设计模式
熟悉FreeMarker（开发过宏者优先）, Jstl(开发过tag lib者优先）等页面展示技术
熟悉UML，有一定的业务建模和数据建模经验。
熟悉面向对象的开发。
熟悉html，CSS。
熟悉主流应用服务器和数据库。
有大型互联网前端开发经验优先
-------------------------------------------------------------
3.Web - Sr. IT specialist - Andriod
五年以上开发经验
精通Android Framework, 3年以上Android开发和Android系统定制经验
精通三大组件（Activity/Service/Broadcast Receiver）及其应用，理解常用组件API及各项特性
精通Android UI体系并能熟练完成各个分辨率下的排版及动画
了解Android底层, 能独立解决各类机型和ROM的适配
熟练掌握Java基础开发
对常用协议及服务器端开发有所了解更佳
熟悉对多媒体和流媒体的处理
有交互式用户体验经验
有互联网或电子商务终端产品经验优先
--------------------------------------------------------------
4.Application Architect - eCommerce
熟悉java开发，7年以上java开发经验，5年以上java web开发经验
至少2年电子商务行业相关开发经验
2-3年WCS 经验 或 精通 FileNet
乐于研究技术，对新技术有较强的敏感，了电子商务行业最新技术，框架，工具
精通UML建模，有较强的撰写架构设计文档能力，能熟练使用设计模式进行架构设计
熟悉常用的开源框架，Spring，Spring MVC, Struts2 , Ibatis
熟悉Websphere application server，jboss， tomcat等应用服务器的使用和配置
有带团队的经验，有一定的组织领导能力
-------------------------------------------------------------------------
5.Application Developer - QT/C++
五年以上开发经验
精通C++，三年以上C++开发经验
精通Windows底层协议和Windows API（主要是Windows XP和Windows 7）
熟练掌握QT开发工具，具备两年以上经验，熟悉Linux
熟练掌握数据结构和常用算法
具备较强的系统分析能力
具备跨平台系统级开发经验者优先（Windows/Linux/Mac/Android）
有互联网或电子商务终端产品经验优先
-------------------------------------------------------------------------
6. Technical Team Leader - QT/C++
8年以上开发经验
精通C++，三年以上C++开发经验
精通Windows底层协议和Windows API（主要是Windows XP和Windows 7）
熟练掌握QT开发工具，具备两年以上经验，熟悉Linux
熟练掌握数据结构和常用算法
----------------------------------------------------------------------------
7.Application Developer - Power Builder
5年以上工作经验，包括3年以上的PowerBuilder开发经验
熟悉Java开发，熟悉POS业务者优先
有零售行业经验者优先
------------------------------------------------------------------------------
8.Technical Team Leader - Power Builder
8年以上工作经验，包括5年以上的PowerBuilder开发经验
精通J2EE开发，熟悉POS业务
必须具备3年以上零售行业经验
--------------------------------------END--------------------------------------
以上职位IBM目前正在热招，请有意者与我联系。
作者: 无聊人士
基于公开密钥的加密过程 比如有两个用户Alice和Bob，Alice想把一段明文通过双钥加密的技术发送给Bob，Bob有一对公钥和私钥，那么加密解密的过程如下：
Bob将他的公开密钥传送给Alice。
Alice用Bob的公开密钥加密她的消息，然后传送给Bob。
Bob用他的私人密钥解密Alice的消息。
Alice使用Bob的公钥进行加密，Bob用自己的私钥进行解密。
基于公开密钥的认证过程 身份认证和加密就不同了，主要用户鉴别用户的真伪。这里我们只要能够鉴别一个用户的私钥是正确的，就可以鉴别这个用户的真伪。
还是Alice和Bob这两个用户，Alice想让Bob知道自己是真实的Alice，而不是假冒的，因此Alice只要使用公钥密码学对文件签名发送给Bob，Bob使用Alice的公钥对文件进行解密，如果可以解密成功，则证明Alice的私钥是正确的，因而就完成了对Alice的身份鉴别。整个身份认证的过程如下：
Alice用她的私人密钥对文件加密，从而对文件签名。
Alice将签名的文件传送给Bob。
Bob用Alice的公钥解密文件，从而验证签名。
Alice使用自己的私钥加密，Bob用Alice的公钥进行解密。
根证书 根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。
总结 根据非对称密码学的原理，每个证书持有人都有一对公钥和私钥，这两把密钥可以互为加解密。公钥是公开的，不需要保密，而私钥是由证书持人自己持有，并且必 须妥善保管和注意保密。
数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机 构的公章）后形成的一个数字文件。CA完成签发证书后，会将证书发布在CA的证书库（目录服务器）中，任何人都可以查询和下载，因此数字证书和公钥一样是 公开的。
可以这样说，数字证书就是经过CA认证过的公钥，而私钥一般情况都是由证书持有者在自己本地生成的，由证书持有者自己负责保管。具体使用时，签名操作是发 送方用私钥进行签名，接受方用发送方证书来验证签名；加密操作则是用接受方的证书进行加密，接受方用自己的私钥进行解密。
转载自：http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html
本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：
第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。
建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例
第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例
第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例
第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例
第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。
第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。
经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。
4K对齐：在xp下使用专用工具，或者直接用win7对硬盘进行分区和格式化！千万不要直接用XP分区！测评软件分值4K对齐后比对齐前能高将近一倍。
开启ACHI模式：安装win7前就在bios中选择ACHI模式，或者安装好系统后，修改注册表（win7下开启achi修改方法：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci；在右窗格中，右键单击“名称”列中的“Start”，然后单击“修改”，将“3”改为“0”。），然后重新开机进入bios中修改为ACHI模式，测评分值再次提高50%以上！！！
安装win7启动很快，SSD硬盘在4K对齐的情况下性能会好些，如果是ghost安装系统的，大家可以用Paragon Alignment Tool去实现无损处理，不需要重装系统。
http://www.verycd.com/topics/2872729/
将处理业务的流程拆分成一个一个链，前面处理完，再派给下一个，类似HTTP中的FILTER
不用安装服务器，内嵌在SPRING容器中，对外支持多种格式的数据，外部系统如要和SPRING INTERGRATION整合，不需要再进行开发
处理流程一般就是，ADAPTER去读取外部数据，转换后放到CHANNEL中，ENDPOINT处理CHANNEL中的数据，委派给下一个CHANNEL，下一个ENDPOINT处理，通过ADAPTER写到外部接口中。
- ADAPTER
外部系统与CHANNEL之间的桥梁，获取外部数据将其放到CHANNEL去，有FTP，JMS，文件系统的
CHANNEL
里面放MESSAGE对象，MESSAGE里面可以放自定义对象，以提供消费者使用
ENDPOINT
CHANNEL的消费者，CHANNEL与ENDPOINT是一对一的关系，所以如果想在一个CHANNE下对应多个ENDPOINT，是做不到的，只能增加CHANNEL
Service Activators：从INPUT CHANNEL中取出一个对象作为参数，调用设置的POJO的方法，将结果放到OUTPUT CHANNEL中
Transformers：对CHANNEL中的对象进行类型转换
决定流向的ENDPOINT：Routers，SPLITER
- 例子
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:stream="http://www.springframework.org/schema/integration/stream"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://www.springframework.org/schema/integration/stream
http://www.springframework.org/schema/integration/stream/spring-integration-stream.xsd">
<gateway id="cafe" service-interface="org.springframework.integration.samples.cafe.Cafe"/>
<channel id="orders"/>
<!-- 此处orders里面的对象是一个一个Message，调用payload则取到Order
调用items则得到OrderItem List，拆分成OrderItem以一个为单位放到
drinks中
-->
<splitter input-channel="orders" expression="payload.items" output-channel="drinks"/>
<channel id="drinks"/>
<!-- 此处drinks里面的对象是一个一个OrderItem，调用iced则取到布尔值
如果是true则放到coldDrinks中，如是false则放到hotDrinks中
-->
<router input-channel="drinks" expression="payload.iced ? 'coldDrinks' : 'hotDrinks'"/>
<channel id="coldDrinks">
<queue capacity="10"/>
</channel>
<service-activator input-channel="coldDrinks" ref="barista" method="prepareColdDrink" output-channel="preparedDrinks"/>
<channel id="hotDrinks">
<queue capacity="10"/>
</channel>
<!-- 将输入通道中的OrderItem转成Drink -->
<service-activator input-channel="hotDrinks" ref="barista" method="prepareHotDrink" output-channel="preparedDrinks"/>
<channel id="preparedDrinks"/>
<!-- 将通道中的Drink按一个Order进行合并成一个List<Order>-->
<aggregator input-channel="preparedDrinks" method="prepareDelivery" output-channel="deliveries">
<beans:bean class="org.springframework.integration.samples.cafe.xml.Waiter"/>
</aggregator>
<stream:stdout-channel-adapter id="deliveries"/>
<beans:bean id="barista" class="org.springframework.integration.samples.cafe.xml.Barista"/>
<poller id="poller" default="true" fixed-delay="1000"/>
</beans:beans>