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