06年写的如何循序渐进向架构师发展，微软的开发绝对

如何逐步发展到2006年写的架构师，请参考：

微软的开发，绝对是一项容易上手、难以改进的技术。而没有三年以上的编码积累就能够成为架构师，基本上是不可能的。尤其是在大型软件项目中，架构师是项目的核心成员，将前一个与后一个联系在一起。因此，RUP方法论也承认架构是核心，体现了4+1视图在整个软件开发过程中的重要作用。架构师必须精通技术，熟悉业务，在软件生命周期的各个阶段基本需要对相关技术有相关的积累和知识储备，没有多年的培训很难达到这个水平。

要成为一名合格的架构师，您首先必须是一名合格或优秀的程序员。编码始终是开发中最重要的技能。只要善于思考和分析编码过程中的问题，就能学到很多相关的知识和技术。因此，在发展过程中，必须重视学习新知识、新技术，学习前人的经验和成果。编码时要考虑的一些问题是：

1.在编码的过程中你有没有自己做单元测试，有没有使用相关的工具做单元测试，如果没有，你不能做单元测试的原因是什么？

2.自己代码泄露率，代码泄露BUG原因分析

3.你是否有意识地重构代码，在重构过程中是否引入了相关设计模式的思想？

4.是否学习C#语言的一些高级特性，比如反射调用、异步处理等。

5.你对这两种分布式技术做过研究和对比分析吗？

6.你是否经常研究开源项目和开源代码，比如，NUnit，，Nant等。

7.你有没有做过对象持久化机制和O/R等相关技术的相关研究？

8.在编码过程中，你平时是否注意常用组件和常用类的复用和抽取？

9.在平时的工作学习中，你是否经常开发一些小工具来提高工作效率，巩固学习知识？

设计和编码其实是密不可分的，严格分离设计和编码的瀑布模型一般只用在大型项目中。编码和设计在时间上的分离并不意味着编码人员不需要思考。编码活动始终是一项创造性的工作。如果你否认这种观点，则意味着编码过程可以完全自动化，无需人工干预。所以，这里讲设计主要是指设计师的系统思维能力。设计师应该比开发人员更高的层次来分析和思考问题。设计师最重要的技能之一就是从现实到抽象的转化，这需要讲方法论。技术人员需要积累面向对象分析设计或结构分析的知识，他们需要有一个强大的数据库。分析和设计能力。一个设计能否成为一名优秀的建筑师，关键在于这种积累的深度和广度。

因此，在设计过程中应考虑的问题有：

1.你目前的分析设计能力能否胜任大中型应用系统，还是只是独立的功能分析设计？

2.在设计过程中是否有意识地考虑了组件的复用以及相关的界面设计指南。将分析模式和设计模式的相关内容应用到自己的设计过程中是否自然。

3.你有没有系统地学习和思考过 XP、RUP、面向对象、结构化和其他方法？

4.你真的了解系统功能性需求和非功能性需求对系统设计的不同指导作用吗？

5.你会根据后来的变化反思自己的设计功能，为什么你的设计不能很好地适应变化吗？

6.您是否经常在设计过程中开发一些原型来验证您的设计想法？

7.您是否专注于技术并开始专业的业务流程分析，专注于业务建模？

如果我们在设计和开发过程中经常关注这些知识和技能，成为一名合格的架构师将是迟早的事。可用于工作发展的知​​识和技能是微不足道的。如果不自觉地学习这些知识，就很难进一步提高自己的技能。我参加过两次微软架构师培训，也有机会参加了北京微软架构峰会的 P&P 学习。培训老师是A.，《微软总部与指南》一书的作者，让我感受到了老外最深的技术。传承，致力于项目开发。

对于建筑中经常用到的知识和技能，有

1.RUP 方法论，4+1 视图。用例驱动的业务建模 -> 分析模型 -> 设计模型

2.用例模式->分析模式->设计模式

3.常见的分布式技术

4.关注安全、异常、日志、性能等非功能性需求。

5.关注应用系统整体业务

一些相关的参考书（微软官网和电骡都可以下载）

来自 网站的参考书

使用 .NET

.NET 数据指南

对于 .NET：和

.NET 指南

-

智能引导

其他架构参考书

在

-

的艺术

模式书籍

- 的 -

UML 和

==================================================== === =

2015年8月，增加建筑设计与外形设计的区别

架构设计

架构设计包括功能架构和技术架构设计。功能架构解决业务流程和功能问题，而技术架构解决非功能需求。两种架构都包括动态和静态方面。对于功能架构的动态部分，业务流程驱动的全局用例和用例驱动的用例实现等；技术架构的动态部分是架构运行机制，而静态部分是为框架、分层等。

功能架构包括全局用例设计，它本身就是用例分析设计的延续，而全局用例分析的建议思路仍然是从业务流程、业务用例建模到系统使用的过程案例建模。全局用例分析清楚后，就可以开始考虑子系统和模块的划分，形成系统的功能架构图。当然，在划分的过程中，必须考虑如何通过CRUD矩阵等分析方法合理划分模块，如何保证模块本身的高内涵。聚和松耦合。

全局用例分析完成后，就涉及到数据模型的设计。数据建模仍然由业务驱动，从最初的业务对象和文档开始，到最终的数据概念模型和逻辑模型。架构设计中的全局数据模型不一定涵盖所有的数据对象和数据表；但是，核心主数据和核心业务单据数据必须覆盖，模型到逻辑模型的层次就足够了。如果采用面向对象的分析方法，这里需要的是UML建模中的概念模型和逻辑模型，体现核心对象与类之间、核心对象与类之间的关系。

将全局用例分析和数据模型构建整合在一起，可以看出两者结合将形成系统完备的领域模型层。一直认为应该在架构设计中引入领域模型的思想，只有领域模型真正关注功能架构，而不是直接关注具体的技术分层和技术实现。

前两个做完后，可以看到一个大系统被分解成多个子系统或模块，那么接下来要考虑的就是模块之间的集成架构了。分析完集成架构，模块之间的接口基本就出来了。界面设计应该是架构设计的另一个核心内容。需要了解的是，架构设计的一个重要作用是架构设计完成后，各个模块可以并行开始大纲设计、详细设计和开发工作。只要每个人都遵循架构设计约定的接口规则。

考虑到集成架构之后的另一个核心内容是公共可复用组件的抽取和识别，包括功能组件和技术组件。有必要确定哪些是可重用的以及如何重用它们。复用级别本身包括数据层复用、逻辑层组件复用、接口层UI组件复用等。复用是架构价值的另一个关键点。

做完这些，接下来架构设计阶段应该做的就是对架构输出进行仿真验证是否成功。分解动作之前已经完成，还需要进行模拟验证，看后续分解内容能否很好的整合和组装。很多时候我们在做建筑设计的时候，往往没有做这个内容，导致建筑设计的一些内容变成了空中楼阁，无法落地。

回顾技术架构设计，先说一下静态部分的内容。这包括软件开发的分层架构、开发框架等，包括开发规范约定、技术平台和语言的选择以及使用的协议。很多时候我们看到谈架构时提到的三层或多层架构，这只是完整架构设计的一小部分。

除了分层架构，接下来要考虑的就是各种非功能性的需求，我们需要如何设计架构。这包括事务、缓存、异常、日志记录、安全性、性能、可用​​性、容错等等。这些点应该在建筑设计中明确说明。由于这些是应用系统中技术平台要考虑的内容，所以应该设计成更通用的技术组件，供上层业务组件使用。有必要了解为什么经常提到 AOP 或可插拔架构。只有这样，才能考虑真正的功能架构设计和功能实现与非功能技术架构的完全解耦，实现进一步的灵活组装。

回到架构设计视图层面，同样需要考虑的是整个应用系统的部署架构。部署架构本身也包括逻辑视图和物理视图。最终开发了如何部署应用程序，这涉及到 IT 基础设施的细节。，也需要考虑清楚。

外形设计

在大纲设计中首先要了解的是，根据架构设计的内容，进一步细化某个模块的设计。架构设计在系统级别，而大纲设计在子系统或模块级别。以建筑物为例，建筑设计就是明确定义建筑物的框架结构，包括地基应该挖多深，核心框架和承重结构如何，每层的结构图应该如何被分成几个大套房。应该解决。每个大套房的水、电、气等管道接入点在哪里等。简单的设计就是拿一个套房考虑如何设计套房的内部，如何划分功能区域，

基于上面的思路，我们看到在设计架构的时候，除了少数核心用例之外，我们会讲具体用例的实现，对于大部分功能我们不会讲具体用例的实现。说到大纲设计，需要进一步分解该模块需要实现哪些功能点，每个具体功能点如何实现都需要考虑。

严格的大纲设计，我们希望当大纲设计的某个功能模块达到时，该模块所涉及的核心类全部出来，所有的类图都出来。数据库设计也进一步细化为本模块的数据库物理模型。对于用例实现分析，在实现分析的过程中，可以看到每个类核心的所有方法都会被分析识别。

有了架构设计的接口，大纲设计也需要进一步细化架构师，接口的具体输入、输出和使用方式，包括模块应该使用哪些外部接口，模块本身提供哪些接口等都需要细化清楚地。在做大纲设计的时候，一定要清楚当前模块在整个应用系统架构中的位置，以及外部集成和交互点。

大纲设计不需要像详细设计那么详细，包括类中的私有方法，方法的具体实现步骤和逻辑，伪代码。但是我们要看到，大纲设计中的核心业务逻辑必须明确设计要实现，实现的机制和方法。很多时候我们到了大纲设计，画了uml的时序图。很多时候，乍一看没有任何意义，都是简单的跨层交互和调用。这应该在架构设计的架构运行机制中明确说明。重点是设计多个业务类之间的交互调用。简单的功能增删改查，无需绘制任何时序图。

其次，在架构设计中给出了各种安全、性能、缓存设计。那么在大纲设计中又出现了一个问题，即在大纲设计中，架构给出的各种实现方案和技术，我们该如何选择和使用。并不是所有的函数都需要缓存，所以需要根据分析明确哪些函数需要缓存，哪些对象需要缓存，以及如何设置缓存本身的时效性。

大纲设计的目的是无论谁拿大纲设计来做，最终确定的功能模块都不会变形。功能模块的最终实现可能在性能、易用性等方面存在问题，但整个功能实现的大框架必须是固定的。

==================================================== === =========

2015-10月更新，架构思维

组件分区和服务接口

基于组件开发的思想很早之前就已经提出了，但是当时组件之间的交互更多的是接口而不是服务，同时也不太关心组件的全生命周期管理。单个组件本身。说到组件，一定不能先说开发和技术框架，而是真正从业务架构和应用架构的角度考虑整个业务系统的组件划分，包括业务组件和技术组件，每一个都要暴露业务和技术服务能力。业务能力的组件化和组件能力的服务化也是SOA一直强调的核心思想。

组件明确划分后，组件间交互需要暴露的服务接口需要优先考虑，即组件只能通过服务进行协作，进一步实现组件间的松耦合。二是考虑单个组件的实现，结合分层开发技术框架，其中涉及分层。这里可以进一步参考领域模型驱动和设计的思路。否则，很容易实现数据库表驱动的功能，而无需关心域模型设计。以及领域逻辑的实现，即虽然技术框架分层，但职责不清，逻辑混乱，多处实现。

组件内部实现的一个关键点是应用层和领域层的关系，即在应用层和领域层之间增加了一个服务层。服务层侧重于服务接口和服务的结合，而具体的业务规则和数据。处理逻辑在存储库类和规则类中实现。注意组件内部应用层和领域层的交互不一定是分布式服务，也可以直接使用内部API服务接口。

开源组件和技术

单一技术往往难以满足互联网业务场景中不同的功能性和非功能性需求。对于不同功能或技术的实现，往往需要选择大量开源的组件或技术进行集成。但是如何将这些独立的技术组件集成到一个有效的整体中变得非常重要。任何技术的选择都必须满足业务需求。模式分析是选择技术的一个关键点，即我们应该选择什么样的开源技术来实现最合适的业务场景，面临什么样的问题。

一是开发技术框架层面，即基于MVC模型的多层框架。完成。表示层相关的技术点比较多，包括一些前端和基于框架的框架的介绍，Ajax的实现，包括目前互联网上的各种前端响应式框架，Html5技术等等。技术框架的选择看似与业务无关，但需要业务场景分析，包括当前开发的应用是否需要同时支持web端和移动app端，是否有外部集成和服务接口暴露，在业务交互和便于使用。性层面有什么要求，这些都需要考虑。

二是实现核心技术能力的技术组件，包括缓存、消息、流程引擎、搜索、安全、任务、日志等诸多内容，往往通过现成的成熟开源技术实现。比如缓存通过实现，消息和事件管理通过or基于全文检索引擎实现，开源ETL技术实现数据集成架构师，开源jbpm流程集成等。在选择这些技术时要注意支付与之前的整体技术框架的整合。技术组件要保持高度的内聚性和独立性，只有技术组件的能力通过服务暴露出来，才能实现与上层应用的集成。为了达成这个，往往需要对开源组件进一步封装和定制，与技术框架形成一个完整的整体，同时不将底层技术组件的复杂性暴露给业务功能的开发过程。此外，互联网应用还涉及外部技术服务能力的引入，如外部邮件通知服务能力、地图能力、支付能力，以及各种外部开放平台开发的各种内容提供服务能力的引入。引入外部服务能力的建议是在技术平台层单独管理和封装，即在技术能力层有一个独立统一的服务代理。

最后是数据库和持久层，包括常见的关系型数据库、半结构化和基于键值的redis等数据库，以及完全基于hdfs的非结构化文件存储能力。针对不同的业务场景和业务对象，往往需要不同的底层数据和存储能力来支持。架构设计时需要考虑如何形成能力完备的数据库服务能力层。

去IOE

De-IOE是近两年互联网架构设计中讨论最多的问题，即去除小型机、集中存储和商业数据库。简单来说，IOE的核心是基于开源的类似Mysql的数据库和集群技术，通过X86服务器硬件资源来实现和原来IOE架构一样的性能和高可用。过去淘宝有基于mysql数据库开源corba实现分布式数据库和集群，现在有开源MyCat实现，核心是提供DaaS服务层和封装实现高性能、高可用的数据库中间件产品.

目前移除IOE的热度有所下降。有两个原因。一是自身技术成熟度和CAP原理约束，二是去掉IOE，引入DaaS数据库中间件后，架构本身复杂度增加。度和应用开发难度。一方面是由于引入了DaaS层引入的分布式事务问题，增加了跨库查询和Sql语句本身的约束。一是在架构设计中，需要考虑前端业务如何组件化，数据存储如何为业务进行分区和分片，横向和纵向如何拆分。

可以说，架构设计中的de-IOE设计，离不开上面提到的组件化和面向服务的设计思想。同时，de-IOE下的组件化是完全组件化的，即组件本身对应的数据库也是独立的。它可以拥有完全独立的硬件资源和全生命周期管理。因此，如果不进行组件划分，可能会导致后期业务功能实现中出现大量跨数据库操作和分布式事务问题。所有这些都应该在建筑设计阶段进行清晰的思考和制定。任何建筑设计中都没有通用的通用架构。

权力下放

我们先来看最简单的场景，即客户端和请求者为A，服务提供者为B，服务提供者已经实现为分布式集群（B1,B2,B3...Bn )，在这个场景中，可以看到请求被转发到不同的集群节点进行处理。但是对于这种分布式架构，集群可以完全平滑弹性扩展，但是问题的关键是A的请求应该转发到哪个B节点处理，有控制层还是管理节点，以及对于大多数分布式应用程序，管理节点本身很难集群和扩展。及时，在很多分布式架构的实现过程中实现了消息请求和数据传输的分离，

为了解决横向弹性扩展的问题，经常会引入集群技术和硬件负载均衡，但这并不是一个完全去中心化的架构。目前，我们所说的去中心化架构没有统一的管理节点，是完全分布式的。，只有在这种架构下是完全去中心化的。为了实现去中心化，它涉及到几个关键点的引入。一种是通过在客户端植入sdk包将请求前移，即客户端在发起请求时已经判断清楚；二是管理职责后移。，即管理端的后续重点是准实时地从每个集群节点采集数据，然后进行分析。