本文目录

• 软件架构设计师最重要的素质有哪些
• 软件产品架构中什么是单体架构、SOA架构、微服务架构
• 在软件项目开发过程中，都有哪些常见的软件架构
• 想成为石油行业的软件架构师有什么建议吗

软件架构设计师最重要的素质有哪些

笔者目前是知名互联网公司的架构师，曾经设计过多个产品的整体架构。我认为软件架构设计师最重要的素质主要分为两方面：其一，技术能力；其二，软实力。软实力与技术两手都要硬，而技术是基础。

技术能力

技术能力是互联网从业者的基本能力。而作为软件架构设计师，不仅需要技术深度，也需要技术广度，还需要战略高度。

成为架构师需要较长时间的一线开发经验的积累。如果单看工作年限，一般 3到5年可以成为初级架构师，5到8年可以成长为中级架构师，8到10年以上可以成长为高级软件架构师，那么现实情况下，具体达到何种水平还要看架构师的实际能力。

一般架构师在技术上主要做如下几件事情：

1. 领域建模

软件开发领域的建模，主要考验架构师的抽象思维。普通工程师通常用代码思考，思维局限在实现、战术的层面，考虑的基本上是某个功能模块的实现细节。而架构师需要负责整个系统的架构，尤其是涉及到一个全局的整体设计，所以需要高屋建瓴，需要在高层、上层的战略层面 进行思考。

2. 技术调研选型

架构师往往能够决定所带领团队的技术选型，选用最优技术组合来进行系统的高可用、高性能架构设计。

3. 系统分析与设计

系统分析与设计的主要技术手段是建模，两者高度重合。

软实力

其实除了技术能力，软实力也必不可少。

1.沟通能力和自我表达能力

沟通能力是基本中的基本，最为重要，最为普遍的素质。技术人员好像容易忽略，想成为架构师就不能忽略。因为架构师要做的第一件事就是与团队成员、项目经理、客户认同沟通，获得认同。

2.一定的魄力和感染力

3.广阔的知识面

架构师的职责有些特殊，多少有点需要创新的要求。虽然有很多现成的架构，但放到具体行业又有不同，不能生搬硬套。那么这时候你就需要专业的架构知识，丰富的业务领域知识，开阔的眼界。

4.多方位思考分析的能力

收集到客户需求和技术团队的反馈后，就要求架构师能够对这些资料进行系统分析，制订可行的解决方法。不仅要求你要从客户的角度考虑，也要从开发，机器等多方面考虑。这就要求架构师具备一定的抽象思维和多方位分析的能力。

除了上面的技术能力和软实力，还需啊哟架构师承担主要的责任，更深入地参与到项目中去。

欢迎关注笔者，每天分享架构干货。

软件产品架构中什么是单体架构、SOA架构、微服务架构

软件产品架构是不断迭代演化的，从单体服务架构发展到现在的服务化、微服务的架构。

单体架构

单体架构就是所有的业务模块都是耦合在一个项目中，开发、部署都在一起；如果其中一个模块需要上线升级，那么所有模块都要一起启停；

在早期，单体架构的项目团队成员需要是“全栈”，因为前端、后端、数据库都是一波人负责，后来开始进行了逻辑分层，团队也分成了前端 UI 团队、后端和 DBA 团队，每个团队都有自己负责的职责。

然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高；另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据。

SOA 架构

为了解决上面的问题，SOA 出现了。

SOA 代表了面向服务的架构，SOA 将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来；

每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的；

SOA 架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性。

SOA 架构时代有两个很重要技术实现方式：Web Service 和 ESB ：前者提供了标准的数据传输协议，后者实现了服务编排和协议转换。

微服务架构

但是随着用户和数据量的进一步增长，SOA 也暴露出来一些缺点，比如 SOAP 协议、XML较重；服务管理不完善；ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险。

在微服务的架构中，各个微服务可以独立开发，独立部署；微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；

微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；

服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；

每个团队的技术栈也可以不相同，只要遵守接口协议即可。

至于微服务和 SOA 架构的区别，我是这样理解的：SOA 架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题；SOA 是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。

当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

在软件项目开发过程中，都有哪些常见的软件架构

软件产品的架构，通常都是随着业务的发展而不断演变的；我从事软件开发行业也有十余年了，遇到过的软件（企业级应用，我是从事Java开发）架构主要有这么几种：

单体架构架构

总的概括来说，单体架构就是应用所有的功能，只有一个代码包，开发和部署都在一起，这是一种比较传统的架构风格；当然，单体架构也有着诸多的缺点：

• 代码越来越多，增加了代码的复杂性；作为开发人员一定深有感触，每当修改一个老方法的时候，一定会格外的小心翼翼，生怕影响了其他的功能；

• 单体应用需要统一技术栈，团队中的开发人员，都需要掌握相同的开发语言和框架；

• 随着开发人员的流动，老员工离开项目组，复杂且庞大的项目代码又让新成员难以阅读和理解，技术债务越积越多；

• 代码都在一个代码包中，就算是修改一个小小的功能，都要把整个项目打包上线；

• 所有的模块都运行在同一个JVM中，非关键性业务可能占用大量的资源，导致关键性业务发生问题；不能单独对某一个模块进行扩展。

SOA架构

因为单体应用架构的种种缺点，已经不能再满足业务需求的时候，于是就出现了SOA架构。

SOA架构的主要思想是把应用程序的模块化组件，通过接口联系起来（接口可以独立于语言、框架、硬件、操作系统）；在SOA架构中，有两个主流实现方式：

• Web Service：使用WSDL定义接口，SOAP协议通信，传输XML数据；缺点是SOAP、XML较重；服务管理不完善；

• ESB：企业服务总线，每个服务提供者通过总线模式插入系统，总线完成服务的编排和转发；但ESB本身就比较中，而且它本身算是一个单点，在软件架构中，单点意味着风险；

微服务架构

微服务的产生，也是由于SOA架构的一些缺点，这里再次印证了这句话，【应用架构的演进的过程通常是被业务逼出来的】。

• 在微服务的架构中，服务拆分粒度更细，提高了复用性；各个微服务可以独立开发，独立部署；

• 微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；

• 微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；

• 服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；

• 每个团队的技术栈也可以不相同，只要遵守接口协议即可。

• 当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

想成为石油行业的软件架构师有什么建议吗

石油行业的软件架构师岗位职责有：

1、负责技术架构设计，重构、优化现有的技术架构，根据业务规划，制定技术规划，制定相关的架构方案；

2、解决重要项目中的关键架构问题和技术难题，负责项目中关键技术难点的攻关和预研，对开发团队进行技术指导和培训；

3、具备较强的逻辑思维和沟通技巧，为技术团队提供可行的、富有成效的、前沿的架构方案；

4、负责软件系统核心框架设计、核心开发、平台搭建及重点技术难点预研；

5、探索通过实践验证的开源技术产品，并将其成功地应用到项目中。

可以通过对岗位职责的剖析，开展岗位知识的学习，希望可以帮到您！