架构这个概念，和计算机科学（包括近几年才成为一级学科的软件工程）的其他术语类似，都是从传统学科借用来的。这是因为计算机科学太年轻、发展太快，来不及形成自己特有的术语和名词。因此，在学习和思考方法上，常常推荐类比法，尝试用一些耳熟能详的事物去理解和解释计算机科学领域的概念，以求“老妪能懂”的效果。
这里介绍的一些内容，大多是个人在学习和实践过程中的一些思考和体会，以及平时的一些学习笔记整理而成，还很不成体系，还有很多需要继续推敲的地方。我会在未来的工作实践中更加深入思考，广泛参考领域内的成果，力求概念准确，容易理解。也欢迎各位同行专家不吝赐教。
关于架构概念的学习和理解，我建议从2个方面入手：
第一、这个概念来自于建筑工程领域，要深入准确地理解，需要看一些建筑方面的资料，比如我会看梁思成《图像中国建筑史》手绘图，从中体会什么是架构；我也会到建筑工地去看建筑施工的一些情况；还会在旅游时有意识地关注不同样式的建筑，体会其架构的不同。“建筑是凝固的音乐”，我们要试图体会架构之美。
第二、对于计算机科学与工程实践中总结出来的一些架构，我们要通过实践来学习和领会。比如对于MVC架构，我们是否联想到用VC++编程时 “ Document/View ” 模型？比如说到三层架构或者多层架构，我们是否考虑到与 “ Client/Server ” 二层架构的关系。
架构工作，不管有没有架构师被指派，其实都是会做的，只是有些时候，架构工作被做了，但没有人意识到。
有明确的架构师，可能会使架构工作更加专业化，可能对提高架构的质量有帮助；但并不是只有架构师才可以做架构工作。
我们应该把架构师当成一种角色，而不仅仅是一个头衔、一个位子。也许有很多人的工作头衔是架构师，但其实际工作和架构关系不大，也可能有些人没有架构师头衔，但其在实际工作中卫架构正在做贡献。
As shown in the figure, TOGAF divides an enterprise architecture into four categories, as follows:
图中，TOGAF把企业架构分为4个部分：
1.Business architecture—Describes the processes the business uses to meet its goals
第一、业务架构。描述业务流程及其达成的业务目标。
2.Application architecture—Describes how specific applications are designed and how they interact with each other
第二、应用架构。描述具体的应用系统的设计以及相互之间的关系。
3.Data architecture—Describes how the enterprise datastores are organized and accessed
第三、数据架构。描述企业的数据存储以及访问方式。
4.Technical architecture—Describes the hardware and software infrastructure that supports applications and their interactions
第四、技术架构。描述基础设施如何支持应用系统的运行及交互。
其中，一个重要的理念是业务架构与应用架构的映射关系（依赖、推理）。应用架构要基于业务架构来考虑，而不是凭空想象。应用是业务能力的提供者。
很多时候，IT部门、以及IT部门的一些人，常常把自己当成数据的所有者，导致认为地制造了藩篱，阻碍数据的共享及访问。其实，IT通常应该只是“司机”的角色。角色错位了，想做事正确？难于缘木求鱼。
这里强调数据，是因为数据是对客观世界的反映，而我们的每一个应用，不过是客观世界的一个视图。
数据是最基本的。数据可以被处理、解释而得到各种信息，而信息又可以被挖掘出有用的知识。我们也可以从中理解当今所谓DT的重要性，以及大数据时代，数据就像工业时代的石油一样重要。
架构是客观存在的，不管我们是否有意识地考虑它。架构不是孤立存在的，它是在具体的上下文环境中，为达到明确的目标而存在的。架构不是“屠龙术”。
“规划-架构-设计”这三者是紧密联系的，常常被混为一体的。为了理解这些概念的联系和区别，我们可以与市政规划进行类比。巴西利亚的建城史、华盛顿的城市规划，其理念值得我们在考虑架构时借鉴。
这里把规划提取出来，而不是与架构混为一谈，是为了有助于理解思考与实践的不同阶段和步骤，帮助思维更加清晰。从软件工程与建筑工程的类比，更容易地理解架构和规划。另外，“自顶向下，逐步细化”的结构化思想也清晰可见。我们推崇面向对象的方法，因为它与客观世界的实际情况更接近，同时，我们也要继承和发扬结构化方法。
所有的架构都是设计，但不是所有的设计都是架构。架构可以认为是宏观设计、顶层设计。
计算模式经历了几个发展阶段，我们选择什么的模式，一方面要跟上技术发展的趋势，另一方面要知道目的是什么。
第一、主机-终端（mainframe）
第二、个人计算机（PC）
第三、客户机/服务器（C/S）
第四、分布式计算（网格、云计算等）
如果规模不大，采用分布式部署意义不大。
对解耦与服务化的关系进行深入思考，尝试理解其本质，明确什么事目的，什么是手段。在做决策的时候，就有助于分清主次。
对于企业应用架构向“微”服务演化，解耦是基础。为此，在程序实现时，“单一职责”原则需要尊循。即使不走服务化道路，降低耦合度也是好的。
是否可以假定：一般情况下，对于特定的语言环境，比如：java和C#，较少的代码行很难实现多个业务功能？于是以子程序(函数，过程，方法)代码行数对工程师执行“单一职责”原则进行度量。
对于不同语言，建议对开发小组的代码行进行统计，经过一段时间的积累得出合适的经验值。一般地，这个代码行数的经验值是和小组的能力相关的。
敏捷方法的使用离不开迭代，我们需要合理地使用这两种方法，才能使我们的交付物越来越逼近用户的真实需求。
这里提到了用户的真实需求，我也多说几句。用户的需求不应该是我们作为BSA或者SME假设出来的，而是我们通过各种有效的方法，比如访谈，从用户那里捕获的。即使我们对用户的建议是正确的，帮助用户完善需求的，也一定要取得用户的完全理解并由用户正式确认。
没有分工，协作就是一句空话。没有明确的分工，就会造成扯皮等现象。分工有助于提高效率和质量。要想分工，就要做好功能分解。而功能分解到合适的粒度，也可以认为是服务化的基础。
微服务所倡导的“单一职责”，其实质也是明确责任，消除歧义。简单即美，大道至简。单一职责恰恰符合这个原则。
从这个对制造别针的分工的描述，你会体会到并发现，很多基本道理是相通的，不论对于生产制造还是软件开发。这就是道法自然。
演化这个词越来越流行了，但仔细想一想，有些情况演化的周期是很长的。就像不可降解的塑料制品，其以无害身份重新回归自然需要几百年甚至更长的时间。考虑演化时，也要结合软件/应用系统的生命周期，否则失去意义。
单靠演化，即使能使架构越来越优化，也可能需要很长的周期，而对于产品或者项目，时间这个约束条件往往是苛刻的。
如前面所阐述，迭代是有条件的。我的建议是：在有规划的基础上进行演化。我们无法得到普适的架构，但可以得到确定领域的通用架构，可以在特定领域通过演化使应用架构逐步优化，逐步与业务架构想适应，提高匹配度。
简化架构，应该成为架构师的常识和日常必须考虑的事情。复杂的架构，特别是强依赖对业务的影响很大：
维护成本增加
集成测试/回归测试成本增加，即使对于微小的改变
引入BUG的可能性增大
对于缩减投资的系统存在单点故障的可能性增大
难于在复杂的系统架构和业务间转换
管理和审计难度大成本高
难于用新技术替换不被支持的过时的技术
分布式的计算模型是以RPC为基础展开的，为解决应用系统间的集成和互操作，为支持语言和平台独立性，经历了几十年的发展历程，从RPC到COM/COM+，以及CORBA和JavaBeans/EJB，进而发展到Web services，实现了跨平台及语言无关。
如果不支持互操作，那么基于异构组件搭建分布式计算平台就是不可能的。
无论服务化还是分布式，都需要进程间通讯（IPC），也包括线程间的通讯。这样，一个好的通讯协议是必要的。HTTP协议的设计初衷据说是为了人-机通讯，后来被用作机器间通讯（M2M），这是服务化/分布式的网络基础。
其他协议，也可以担此大任。只是从复杂性、使用难易程度、普遍性等方面要多加考虑。比如传统的web services，其SOAP协议除了可以基于HTTP，还可以基于 SMTP。
通过调研，我们发现企业应用系统面临的三个主要痛点：
第一、灵活性差
第二、交付时间长，动辄3个月或者半年乃至一年
第三、性能差，用户体验不好
针对灵活性差，我们提出要降低耦合度，这也是软件工程中的一个基本原则。这样的问题，反映出我们的软件设计、开发水平不高的现实，专业性查，很多时候，很多开发人员还分不清程序和软件的区别，还只停留在功能实现的低水平上。这不单是靠架构优化能解决的，而是要靠提高整体开发水平来解决。
针对交付时间长，我们考虑从提高重用和构件化等方面着手，不断积累企业应用构件库。这好比我们烧砖建房，我们从实际需求出发，逐步建立并不断更新有限的砖块规格集合，未来所有的房屋都使用标准件来搭建。
针对性能问题，我们在构件化的基础上逐步地适度地服务化，这样讲是因为我们认为，不是所有的应用系统都适合服务化。有了这样的基础，我们对系统的扩展，包括水平和垂直，都会变得容易，分布式的部署水到渠成。
通过前面的痛点及解决方案的分析，我们总结了好的企业应用架构的三要素，同时也作为我们的三步走战略：
第一、组件化/构件化
第二、服务化
第三、分布式环境
“对象-组件-服务”示意图希望表达三者之间的关系，有助于理解组件化是服务化的基础。对于非面向对象语言程序设计，也可以支持服务化，此处不做深入探讨。
服务化是和多进程/多线程相关的，是降低应用部署粒度的过程。而分布式部署，其基础是进程/线程间的通信。要理解RPC，最好首先理解IPC，这个前面已有论述。
这是我们针对企业应用系统服务化而开发的模型，考虑了多种逻辑和物理架构。结合企业应用，基于多层分布式体系结构而进行的实例化。我们希望该模型能够覆盖企业的全部应用，包括基于package的二次开发系统（如SAP，Oracle），基于SaaS的云应用（如SFDC），以及基于Java/.Net自开发的一些应用。我们正在实践中逐步完善这个模型，希望能为企业架构的优化助力。
这里希望对这几个相关的概念做简单的对比，以便大家在学习、看文章时、讨论时，能够在合适的语境。
Web Service，由于需要WSDL以及skeleton，导致比较“重”，但支持复杂的数据结构。
Micro Service，主要是指粒度小；再有就是不需要WSDL以及skeleton，因此轻量。
对于微服务（Micro-services）和大数据(Big Data)这2个术语的理解，不能望文生义。微是为了表示粒度的足够小，但小到什么程度合适，一方面见仁见智，另一方面应该结合实际项目实际问题。拿瓷砖和马赛克为例，我们不会在需要使用瓷砖的地方都使用马赛克来拼凑。
'webservice' and 'microservice' aren't mutually exclusive terms, nor do they have strict, objective definitions. It's possible that all of your web services already are microservices by many people's definitions.
Web services architecture: the service provider sends a WSDL file to UDDI. The service requester contacts UDDI to find out who is the provider for the data it needs, and then it contacts the service provider using the SOAP protocol. The service provider validates the service request and sends structured data in an XML file, using the SOAP protocol. This XML file would be validated again by the service requester using an XSD file.
How big is a microservice?
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.
This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.
这里想强调的是SOA与Web Services不是一个概念，很多时候，这2个概念却常常被不恰当地混用。
The vision behind SOA and Web Services comes from enterprise and organization needs to save development effort and money by reusing software in the form of components.
在SOA和WebServices背后的想法是，企业和组织希望通过复用组件以达到节省成本的目的。
The Web Services vision achieves reuse by building service components that autonomously discover at runtime other needed components needed to solve a business process.
Web Services的愿景是，通过构建服务组件，支持自动发现解决业务流程问题，实现对复用的支持。
The SOA vision achieves reuse by aligning new software development projects to business goals through a governance plan.
SOA的愿景是，通过治理使新的软件项目和业务目标一致
Both expect a registry of services will help avoid building the same software component twice.
二者都希望通过注册机制避免童颜个的组件开发两次（重复开发）。
在 Sam Newman 的《Building Microservices》一书中，SOA 和 Micorservices 的区别给出了定义：
You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.
你可以把微服务想成是 SOA 的一种实践方式，正如 XP 或 Scrum 是敏捷软件开发的实践方式。
面向服务架构（SOA）的概念已有十多年，它提出了一种架构设计思想， 但没有给出标准的参考实现，当微服务架构出现时， 其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签，而直接称其为微服务架构（Microservices Architecture Style）， 让人以为是一套全新的架构思想，但事实上它的本质依然是 SOA 的一种实践方式。
The core difference between SOA and microservices lies in the size and scope. As the word 'micro' suggests, it has to be significantly smaller than what SOA tends to be.
Microservice is a small(er) independently deployable unit. Beware of very small microservice antipattern - nanoservice.
A SOA can be either a monolith or it can be comprised of multiple microservices.
SOAP, or Simple Object Access Protocol, is an architectural concept that was created in 1998 by Dave Winer, Don Box, and Bob Atkinson, in collaboration with Microsoft. Designed explicitly for the purpose of making communication between web services easier.
SOAP，简单对象访问协议，是在1998年由Dave Winer, Don Box, and Bob Atkinson, in collaboration 在微软公司合作时创造的架构概念，设计的初衷是为了web service之间通讯更容易。
REST, or Representational State Transfer, was created in 2000 by Roy Fielding in UC, Irvine; later versions of this architecture were created in collaboration with the W3C Technical Architecture Group (TAG).
REST，表述性状态转移，由Roy Fielding在2000年在UC, Irvine创造，后续的版本是与W3C的TAG合作推出的。
While SOAP aimed to be a complete system, REST was designed to be more lightweight for building the following right into the design.
SOAP的目标识一个完整的系统，而REST倾向于更加轻量。
Extensibility through user generated extensions tying into the base structure;
Neutrality by operating over any transport protocol;
Independence by allowing variable programming paradigms and structures;
Large Data Handling by handling conversions, calculations, etc. asynchronously;
Scalability by using cached data from the client and intermediate nodes built into HTTP to self-define;
Portability by tying the transfer of data to the program code during transfer;
Extensibility by allowing individual elements of the greater network to develop independent of one another, using uniform interfaces.
https:///2yko4TbC8cI?t=15m53s
Edit : Here is another video by Martin Fowler, talking about difference between Microservices and SOA.
https:///wgdBVIX9ifA?t=13m10s
微信号：freshmanTechnology
