笑笑谈科技分享编程基础知识，科技发展动态，与大家共同学习进步，请多多支持关注
单体架构
来自网络，侵则必删
web单体架构就是将所有功能打成一个war包，用一个容器运行，比如：tomcat，部署到生产环境里。war包里的资源文件包含了前端UI，业务服务以及数据库访问功能。对于运维人员，部署一套单体架构的web应用，轻松简单方便；对于开发人员，只需生成一个war包就可以；但随着访问量的增加，业务需求量的扩大，用多个单体架构应用实现，随之而来的问题也逐渐浮出水面：
应用出现问题，由于各个服务模块依赖性很强，需要定位所有服务模块来寻找问题在原有应用中进行业务扩展，新的功能可能会影响旧的功能，应该的稳定性有待考验应用健壮性不高，只要其中任何一个业务服务出现问题，都会导致整个应用性能以及功能的影响出现某个核心业务访问量大的情景，就要对整个应用进行集群处理，对硬件的空间以及cpu占用冗余数据过多，造成资源的浪费。针对以上单体架构缺陷，演进出了RPC架构
RPC架构
RPC架构就是进程间的通信，将单体架构应用的业务服务拆分成多个服务，每个服务通信采用RPC通信，每个服务都是互相独立运行，这样如果某个业务服务出现问题而停止，不影响其他业务服务的正常运行，其主要目的是解耦合，做到服务高可用。
RPC通信过程
RPC的通信实质上底层的socket通信，利用java的序列化机制，反射对应服务的函数，调用对应服务的功能。图中是服务A向服务B的整体通信过程。
RPC虽然实现了业务服务低耦合，实现业务服务的高可用，解决了单体架构的缺陷，但是随着服务的增多，各个服务之间调用关系会越来越复杂，各个服务所调用的远程服务url越来越多，管理起来较复杂，单纯使用RPC显得不合理。这个时候就用到SOA架构优势
SOA架构
SOA是一个面向服务的架构，与RPC不同的是，SOA拥有各个服务的消息通信总线，每个服务都可以通过该总线ESB通信，ESB拥有负载均衡功能，这样省去url管理以及负载均衡难度；而且SOA架构可以对各个服务的生命周期以及运行状态监控，做到整体态势的监控管理。SOA架构解决了各个服务的通信依赖性，进一步的加深各个服务低耦合度
微服务架构
1. 细粒度
来自官网
微服务架构与SOA架构的主要区别在于粒度粗细之分，SOA架构所有服务是根据业务来划分，实际上每个服务对应着一个业务的功能，粒度比较粗。随着需求多样化，有些业务的某些更细功能用到的比较少，如果该业务服务集群的多，就会造成那些更细功能占用资源的浪费，这时候微服务的优势出现在这里。微服务以最细粒度的服务划分，追求资源的高利用率。
2. 去中心化
每个服务都各自管理自己的数据库，减少数据的互相影响，进一步加深了各个服务的低耦合性，与SOA架构相比，实际上微服务做到了去中心化功能，各个服务协调运行完成一个业务功能，各个服务都可以根据不同的语言实现完成，真正实现不同团队完成业务功能的集成，最大化的发挥敏捷式开发优势，做到快捷，高效，降低产品维护成本。
3. 技术要求
微服务虽然有很多优势，但对开发团队以及产品需求更高的要求，产品经理必须要能对业务非常熟悉，能将各个项目细分到各个业务最大限度的低耦合；研发团队在开发过程中，对分布式数据一致性要着重考虑，尽最大化的避免数据脏读与冗余；
结束语
框架发展至今，也不是微服务架构就是最好的，世上没有完美的框架，只有最适合的框架才是最完美的，在项目初期，框架选择尤为重要，针对上面的介绍，希望能帮你对框架的一些整体认识，在框架选型方面有所帮助。
如果觉得《web技术分享：从单体到微服务的架构演进过程》对你有帮助，请点赞、收藏，并留下你的观点哦！
