软件架构总是随着业务的发展而发展。我从事软件开发十多年了。我从事过几种企业级软件应用的Java开发架构。SOA的主要思想是通过接口连接应用程序的模块化组件，接口可以独立于语言框架和硬件操作系统。在SOA中，有两种主流的实现方式。
在软件项目开发过程中，都有哪些常见的软件架构？
软件产品的架构，通常都是随着业务的发展而不断演变的我从事软件开发行业也有十余年了，遇到过的软件企业级应用，我是从事Java开发架构主要有这么几种单体架构架构总的概括来说，单体架构就是应用所有的功能，只有一个代码包，开发和部署都在一起，这是一种比较传统的架构风格当然，单体架构也有着诸多的缺点代码越来越多，增加了代码的复杂性作为开发人员一定深有感触，每当修改一个老方法的时候，一定会格外的小心翼翼，生怕影响了其他的功能单体应用需要统一技术栈，团队中的开发人员，都需要掌握相同的开发语言和框架随着开发人员的流动，老员工离开项目组，复杂且庞大的项目代码又让新成员难以阅读和理解，技术债务越积越多代码都在一个代码包中，就算是修改一个小小的功能，都要把整个项目打包上线所有的模块都运行在同一个JVM中，非关键性业务可能占用大量的资源，导致关键性业务发生问题不能单独对某一个模块进行扩展。
SOA架构因为单体应用架构的种种缺点，已经不能再满足业务需求的时候，于是就出现了SOA架构。SOA架构的主要思想是把应用程序的模块化组件，通过接口联系起来接口可以独立于语言框架硬件操作系统在SOA架构中，有两个主流实现方式Web Service使用WSDL定义接口，SOAP协议通信，传输XML数据缺点是SOAPXML较重服务管理不完善ESB企业服务总线，每个服务提供者通过总线模式插入系统，总线完成服务的编排和转发但ESB本身就比较中，而且它本身算是一个单点，在软件架构中，单点意味着风险微服务架构微服务的产生，也是由于SOA架构的一些缺点，这里再次印证了这句话，应用架构的演进的过程通常是被业务逼出来的。
在微服务的架构中，服务拆分的粒度更细，复用性提高。每个微服务都可以独立开发。独立部署的微服务之间通常使用Restful API通信，传输格式通常选择JSON微服务，这是SOA架构的延续。与单个应用相比，它们大大提高了系统的负载能力，解决了应用的高并发，降低了服务之间的耦合度。而且项目团队可以分成几个小团队，每个微服务都可以敏捷地开发部署，每个团队的技术栈可以不一样，只要遵循接口协议就可以。
