微服务架构的优缺点
微服务架构是⼀种将单个应⽤程序作为⼀套⼩型服务开发的⽅法，每种应⽤程序都在⾃⼰的进程中运⾏，采⽤⼀组服务的⽅式来构建⼀个应⽤，服务独⽴部署在不同的进程中，不同服务通过⼀些轻量级交互机制来通信的架构思路。
独⽴性
在开发层⾯，每个微服务基本上都是各⾃独⽴的项⽬（project），⽽对应各⾃独⽴项⽬的研发团队基本上也是独⽴对应，这样的结构保证了微服务的并⾏研发，并且各⾃快速迭代，不会因为所有研发都投⼊⼀个近乎单点的项⽬，从⽽造成开发阶段的瓶颈。开发阶段的独⽴，保证了微服务的研发可以⾼效进⾏。
可扩展性
我们可以快速地添加服务集的实例，提升整个微服务集的服务能⼒，⽽在传统 Monolith 模式下，为了能够提升服务能⼒，很多时候必须强化和扩展单⼀结点的服务能⼒来达成。如果单结点服务能⼒已经扩展到了极限，再寻求扩展的话，就得从软件到硬件整体进⾏重构。
隔离性
隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独⽴的运⾏单元之后，任何⼀个或者多个微服务的失败都将只影响⾃⼰或者少量其他微服务，⽽不会⼤⾯积地波及整个服务运⾏体系。
微服务项目技术架构在架构设计上有⼀种实践模式，即隔板模式（Bulkhead Pattern），这种架构设计模式的⾸要⽬的就是为了隔离系统中的各个功能单元和实体，使得系统不会因为⼀个单元或者服务的失败⽽导致整体失败。
服务独⽴维护，分⼯明确
每个微服务都可以交由⼀个⼩团队进⾏开发，测试维护部署，并对整个⽣命周期负责，当我们将每个微服务都隔离为独⽴的运⾏单元之后，任何⼀个或者多个微服务的失败都将只影响⾃⼰或者少量其他微服务，⽽不会⼤⾯积地波及整个服务。
当然，没有完美⽆瑕的技术，微服务也有⾃⾝的不⾜：
微服务应⽤是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。他们必须写代码来处理消息传递中速度过慢或者不可⽤等局部失效问题。当然这并不是什么难事，但相对于单体式应⽤中通过语⾔层级的⽅法或者进程调⽤，微服务下这种技术显得更复杂⼀些。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。