软件架构总是随着业务的发展而发展。我从事软件开发十多年了。我从事过几种企业级软件应用的Java开发架构。单片架构一般来说，单片架构是所有功能的应用，只有一个代码包，开发和部署在一起，这是传统的架构风格。当然，单片架构也有很多缺点。
在软件项目开发过程中，都有哪些常见的软件架构？
软件产品的架构，通常都是随着业务的发展而不断演变的我从事软件开发行业也有十余年了，遇到过的软件企业级应用，我是从事Java开发架构主要有这么几种单体架构架构总的概括来说，单体架构就是应用所有的功能，只有一个代码包，开发和部署都在一起，这是一种比较传统的架构风格当然，单体架构也有着诸多的缺点代码越来越多，增加了代码的复杂性作为开发人员一定深有感触，每当修改一个老方法的时候，一定会格外的小心翼翼，生怕影响了其他的功能单体应用需要统一技术栈，团队中的开发人员，都需要掌握相同的开发语言和框架随着开发人员的流动，老员工离开项目组，复杂且庞大的项目代码又让新成员难以阅读和理解，技术债务越积越多代码都在一个代码包中，就算是修改一个小小的功能，都要把整个项目打包上线所有的模块都运行在同一个JVM中，非关键性业务可能占用大量的资源，导致关键性业务发生问题不能单独对某一个模块进行扩展。
SOA架构因为单体应用架构的种种缺点，已经不能再满足业务需求的时候，于是就出现了SOA架构。SOA架构的主要思想是把应用程序的模块化组件，通过接口联系起来接口可以独立于语言框架硬件操作系统在SOA架构中，有两个主流实现方式Web Service使用WSDL定义接口，SOAP协议通信，传输XML数据缺点是SOAPXML较重服务管理不完善ESB企业服务总线，每个服务提供者通过总线模式插入系统，总线完成服务的编排和转发但ESB本身就比较中，而且它本身算是一个单点，在软件架构中，单点意味着风险微服务架构微服务的产生，也是由于SOA架构的一些缺点，这里再次印证了这句话，应用架构的演进的过程通常是被业务逼出来的。
在微服务的架构中，服务拆分粒度更细，提高了复用性各个微服务可以独立开发，独立部署微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署每个团队的技术栈也可以不相同，只要遵守接口协议即可。
在软件架构中，有哪些负载均衡？它们起到的作用是什么？
如果项目的用户量少访问量不大数据量也不多的时候，一台服务器足以支撑，那么直接项目部署一套，直接访问使用就可以了，但是当用户和数据量不断增多，访问量并发量不断增加，一台服务器不在能够支撑业务的时候，就需要使用多台机器，设计高性能的集群来应对。那么当我部署了多台服务器这里假如是两台，那么调用方是如何访问的呢？服务方如何均衡访问的流量呢？这时候就需要引出负载均衡了。
负载均衡就是通过一定的策略，把用户的访问量均匀地转发给后端的服务器负载均衡可以提高系统的服务能力和高可用性。负载均衡分类常见的负载均衡技术有三种DNS负载均衡大概的原理是，当用户访问域名的时候，需要先通过DNS解析域名，找到对应的IP地址，在这个过程中，可以让DNS服务器，根据用户的地理位置，返回不同的IP，这样就可以实现负载均衡，同时也可以提升用户的访问速度。
软件负载平衡使用软件来分配流量。有一些基于传输层的负载均衡，如LVS，还有一些基于应用层。比如Nginx软件负载均衡非常简单，只需要在服务器上部署配置就可以实现硬件负载均衡。硬件是用来实现负载均衡的，比如F5F5 Network Big-IP，这是一种性能很高，价格非常贵的网络设备。
