烟囱式系统建设的弊端:
1.重复功能的建设和维护带来的重复投资
2.烟囱式系统交互集成和协做成本高
3.不利于业务的沉淀和持续发展
1.重复功能的建设和维护带来的重复投资
这一条很好理解就是当咱们公司内部拥有多套子系统的时候,势必会带来一些重复性的工做,好比说公司内部OA系统和报表系统、两个系统按照单独的设计都会存在用户管理功能,若是某一天公司须要在加一套管理系统的话,那么在管理系统中还须要添加一套用户管理的逻辑,该重复功能的建设工做和维护势必会带来时间、资源上的浪费。
2.烟囱式系统交互集成和协做成本高
随着公司内部系统业务不断的增长以及完善,多个系统之间的集成和交互也将变得困难,多系统之间的协做、沟通成本较高,例如公司有一套mes系统(生产制造系统)该系统当中有wip模块、alm模块当有一天我新建了一个报表系统去统计使用人数,那我须要从两个系统当中分别去获取用户,带来的时间成本和沟通成本是比较高昂的
3.不利于业务的沉淀和持续发展
不利于产品的快速跟新和迭代,当今互联网项目每周每个月都在不停的变化、市场的反馈根业务上的须要都须要获得快速的响应,而传统系统的迭代周期长对业务响应不及时。
为何要微服务化
1.协做成本高,业务响应慢 传统单体架构若是功能模块100个以上通常的公司内部按照功能模块进行划分工做,每一次新版本上线总会出现各类问题,例如分支合并冲突、代码不一致、等各类问题也会带来很大的协做成本,沟通成本。
2.系统复杂度增长难以维护
单体架构随着业务量不断的增长和扩展以及随着组织人员的变化,业务代码也会变得愈来愈难以维护,一次小小的改动可能会带来灾难行的风险!
3.错误不能隔离
当全部的业务功能模块都汇集在一个程序集当中,若是其中的某一个小的功能模块出现问题,那么都有可能会形成整个系统的崩溃
4.数据库链接能力很难扩展
数据库集群的链接数量是有限的,当数据库的链接数量资源随着实例的增长将难以保证
5.应用扩展能力差
单体架构不可以按需扩展,例如某一天咱们的网站当中部分业务模块访问量暴增,若是咱们要对服务扩展只能把整个系统进行打包、发布而不能针对特定的模块进行扩容
综合上述烟囱式建设模式带来的一些弊端接下来说到了soa方法,SOA的主要特色有以下几种:
- 面向服务的分布式计算
- 服务间松耦合
- 支持服务的组装
- 服务注册和自动发现
- 以服务契约方式定义服务交互方式
SOA架构带来的真正核心意义价值:服务重用。
举例公司内部有多个系统进行维护,WIP、ALM、报表等系统,采用SOA架构思想把用户管理单独拿出来做为一个服务提供给上述几个系统使用、此时咱们发现该架构的设计可以最大程度的避免了“重复建设工做”,从这方面也体现出来了SOA的核心价值:服务重用
1.传统单体架构数据库

优势后端
- 易于开发
- 单体应用程序开发相对简单,容易理解。
- 易于测试
- 单体架构全部功能都聚合在一块儿,启动集成开发环境一旦启动该进程,就能够当即开始系统测试或者功能测试
- 易于部署
- 单体架构部署的话直接把环境发布部署到iis便可
缺点api
- 开发成本高
- 代码重复率高,需求变动困难,没法知足新业务快速上线和敏捷交付
- 代码维护成本高
- 本地代码不断迭代、变动代码难以维护和理解,关键性的代码改动一处多处会受影响
- 部署成本高
- 每次小的改动都得须要部署整个程序
- 测试成本高
- 同部署成本高
- 可靠性差
- 某个bug,例如死循环、事务死锁等会致使整个系统没法运行,宕机。
- 可伸缩性差
- 水平扩展只能对整个系统进行扩展,没法针对某一个功能模块进行扩展
微服务服务器
优势架构
- 单个微服务都很小,可以根据实际的访问量按需扩展
- 微服务可以被小团队独立开发便于理解和维护
- 可伸缩弹性架构、当服务器压力太高的时候可动态注册服务,分摊服务器压力。
- 统一鉴权中心,单点登陆、降级、熔断、限流策略避免重复造轮子
- 微服务是松耦合,是有功能意义的服务,不管是开发阶段、或者是部署和测试阶段都是独立的
- 微服务能使用不一样的语言开发
- 每一个微服务都有本身的存储能力,能够有本身的数据库,也能够统一数据库
- 减小重复开发
容器部署优势负载均衡
- 传统的部署方法可能致使本地测试没问题,可是发布线上会出现各类问题
- 容器化服务便于安装部署、节省内存空间、后期可集成ci cd
- 容器化服务启动快捷方便一般可达到秒级启动和销毁
先后端分离优势前后端分离
缺点分布式
- 微服务架构可能带来过来的操做
- 链路变长,排查问题难度增长,分布式系统复杂很差管理
- 中心化的微服务架构可能会带来若是某台服务及宕机或者出现异动那么有可能致使整个架构所有瘫痪
中心化的微服务微服务
注册中心的好处是,若是在作服务集群负载均衡的时候例如wip多个服务器都得写到配置文件,首先方式很low其次不利于扩展,采用服务注册的方式调用服务实例名 ,而且提供健康检测、异常宕机反馈给api网关测试
稳定性是网关很是重要的一环,监控、告警须要作的很完善才能够,好比接口调用量、响应时间、异常、错误码、成功率等相关的监控告警,还有线程池相关的一些,好比活跃线程数、队列积压等,还有些系统层面的,好比CPU、内存。
网关是全部服务的入口,对于网关的稳定性的要求相对于其余服务会更高,最好可以一直稳定的运行,尽可能少重启,但当新增功能、或者加日志排查问题时,不可避免的须要从新发布,所以能够参考Zuul的方式,将全部的核心功能都基于不一样的拦截器实现,拦截器的代码采用Groovy编写,存储到数据库中,支持动态加载、编译、运行,这样在出了问题的时候可以第一时间定位并解决,而且若是网关须要开发新功能,只须要增长新的拦截器,并动态添加到网关便可,不须要从新发布。