微服务架构(1)之前言

微服务可能是一把双刃剑，一方面他把单个问题域的复杂性降低了，服务可以独立更新发布测试；但另一方面，由于是多个技术栈支撑的整体系统,所以，在维护和交付的时候难度增加了，一旦出现问题，所有单个服务都要进行查找排除，所谓有一利必有一弊，在意识到问题的严重性后，我们要尽量把问题最小化。

一、传统的三层架构

• 表示层

表示层，可以理解为OSI模型中的表示层，即人可以看见，可以输入或者交互的部分，比如，信息的显示，音乐视频的播放。在Javeweb中就是web接口层

• 业务逻辑层

业务层，就是对用户输入的数据，进行处理的，比如说，当用户输入价格，然后业务层根据用户的等级，去算出优惠信息，然后确定最后支付的价格，然后返回

• 数据访问层

在用户和应用的交互过程中，必然会产生数据，而存入数据库，这一层只对数据库进行操作，拒绝耦合

三层架构的优势

• 1.一般公司对应用开发人员工作分配，会根据功能划分，或者是层划分，这样的好处，就是职责清晰，公司可以根据能力去选择人员开发，这样不仅有利于项目，也聚焦于个人专业技能的发展和培养

• 2.代码职责清楚，各层定义接口，并将接口和实现分离，可以很容易地用不同的实现来替换原有的层次实现，从而有效降低层与层之间的依赖，也降低后期的维护成功。

劣势

• 1.虽然软件上采用三层架构设计，但是这只是软件上的表现，在物理上的体现，就是打包部署，不考虑负载均衡以及水平扩展，最终还是运行在同一台机器的同一个进程中，虽然这样方便了开发人员开发，运行，也很容易进行水平扩展，但是在纵向扩展上，很难扩展，因为这个始终是一个程序包。

• 2.随着应用程序的功能越来越多，团队越来越大，人数越来越多，响应发的沟通成本和管理成本就水涨船高，尤其是在代码提交的时候

• 3.新人培养时间周期长

• 4.单块架构的开发模式，在分工时往往以技能为单位，比如用户体验团队，服务端团队，数据库团队，这样的划分，可能会导致任何功能上的改变，都要进行跨团队的沟通和协调

小结

互联网时代，产品创新快，成本低，需求变化快，用户群体庞大，开发周期要求短，无论是从维护成本上，或者人员培养成本，技术沟通成本及系统扩展成本都在相应增加，所以微服务架构就突然出现，接下来，一起学习，让我们对微服务架构有一个新的认识吧。

文章来源: springlearn.blog.csdn.net，作者：西魏陶渊明，版权归原作者所有，如需转载，请联系作者。

原文链接：springlearn.blog.csdn.net/article/details/102425279