原文：

架构师在软件行业一直有很高的位置，并且在开会中的架构师都带有主角光环。 架构师是可以说是软件的设计者，运用我们学会就会忘记的23种设计模式、企业架构模式、面向对象编程，来设计系统基础架构。基础架构开发完成后，程序员就可以愉快的在系统的基础框架里舔砖加瓦，最终完成项目的开发。

微服务和架构师有什么关系？因为微服务也是一种架构，所以还需要架构师来设计。先不说架构师了，架构师在微服务作用放到最后说。先说说传统的架构。传统的三层架构传统的web系统一般是采用三层架构来开发系统的，三层架构既视图层、业务层、数据层的架构。视图层负责与用户交互，业务层负责处理业务逻辑，数据层负责数据的处理。一般系统上线发布，都是打成一个包，部署在中间件中，业务代码全在一个进程中。对于需要高可用的系统，架构会设计成集群，web应用会运行在多个主机中。这种架构的系统看起来没什么问题，不重要的系统，单例，一个进程。重要的系统，集群，多实例。其实这种架构问题很多，不然也不会有现在的微服务模式。 传统架构的缺点：1、难以维护: 代码极度臃肿，有些小系统的代码竟然达到100m甚至1G，里面不知有多少无用的包和个版本积累的无用代码，代码难以维护。 2、稳定性差： 稳定性差主要有几个原因： 1、代码原因：代码越多，bug就回去越多。因为代码都是运作在一个进程中，某块代码出现问题，就会导致系统运行缓慢、不可用，甚至进程崩溃问题。 2、中间件原因：中间件也有bug，有时也会罢工，它一罢工，系统就整个崩溃了。 3、依赖系统问题：依赖系统出问题了，也可能会导致本系统最终不可用。 4、其他原因：数据库、操作系统、硬件存储等。 3、难以扩展： 系统不好集群，集群了，负载不一定好用。无法动态扩展。 4、发布成本高： 因为是集成到一个包，所以修改的代码难以确定修改的范围和影响的范围，不知道影响范围，有时需要全面测试，直接导致测试周期拉长，上线后修改的代码还可能引起其他问题。微服务是什么？微服务，不同的人理解不同。我的理解，微服务在软件中，就是一种软件架构模式。是系统的调用架构模式，是将系统分割成单独模块，提供api工其他模块调用，可以单独部署，单独运行在服务器之中，可以说是天生的分布式系统。微服务解决了什么问题？1、稳定性提升：业务按模块划分，实现了进程级别、容器级别甚至操作系统级别的隔离，互不影响。运维的核心可以从解决问题转变成主动发现问题。 2、易部署：轻量级部署，影响范围可控，系统其他模块可以正常运行。 3、易交付：因为代码较少，测试较快，说要交付周期缩短了。 4、易扩展：模块代码是轻量级的，容易快速扩展。微服务的通信是什么？ 模块相互调用就需要通信，通信首先方式是rpc，以保证其性能。对接过soa系统开发人员可能比较清楚，soa用的是http协议，调用都是访问网页一样，性能较差。可以说，没有好的rpc框架，就不会有好的微服务。现在的rpc框架有Netty，dubbo，HSF，ZooKeeper。微服务是不是糖衣炮弹，有没有陷阱？ 微服务是不是糖衣炮弹，搞不好真是，为了避免炸伤自己，有些陷阱还是要注意。1、减少多样性：因为为微服务是可以使用不用语言实现的，会增加项目的后期维护成本，最好一个项目都开发语言不要超过两种，不要java、c、c++、c#、python、delphi、node.js、go等各类语言都来了。 2、要有熔断机制：微服务因为是模块化，模块之间调用会非常频繁，如果没有熔断机制，一旦一个模块出现问题，可能会导致调用链出现问题，最后导致系统完全崩溃。3、一定要有服务监控：一定要有服务监控，最好可以监控每个服务的调用链，及时发现问题。要不要用微服务？ 微服务是一种软件组织、协作的模式。对于一般的管理系统，不建议采用微服务模式，但是可以将容易出问题或者需要与其他系统交互的模块，进行拆分，做成微服务，这样可以进一步提升系统的稳定性。对于大型系统是否采用，这个就需要软件的架构师去评估了。