微服务架构的概念
微服务（或称微服务架构）是一种云原生架构方法，在单个应用中包含众多松散耦合且可单独部署的小型组件或服务。 这些服务通常拥有自己的技术栈，包括数据库和数据管理模型；通过一个REST API、事件流和消息代理组合彼此通信；以及按照业务能力进行组织，具有通常称为有界上下文的服务分隔线。
定义来源What are Microservices? | IBM
翻译过来大白话就是，将许多服务拆成一个一个微小的单元，它们相互独立，一个人也能活的很好，但是它们常常需要在一起相互合作，来完成复杂而牛逼的事
微服务适合什么场景？
适应大型的、复杂的、高性能、分布式、需要快速迭代的业务场景，比如说直播、电商、游戏、搜索、社交媒体、互联网这些需要快速响应市场变化和技术创新的场景都非常适合微服务的架构。对于我们安全运维开发团队而言，给SRE运维团队开发的安全运营中心，有复杂的业务场景，并需要根据SRE的需求进行快速迭代。
这里可以说一点题外话，就是我们团队是经历过整个架构的割接的，我刚进团队的时候安全运营中心只有简单的功能，基于低代码平台进行开发的，并且许多功能并未实现自动化，都需要人为统计数据和做图表，手动发邮件来进行“人肉运维”，经过了两年的逐渐演进、兼容和替代，才最终演进到比较完备的微服务架构。
微服务又有哪些优缺点呢？
优点：
- 更易于组件通用化：一些公共服务组件，比如统一鉴权、审计日志、通知中心以及一些中间件Kafka、ElasticSearch、LB、Redis等都可以做成微服务的形式，可以集成到一个微服务中为其他的微服务提供服务，做成通用化的组件
- 灵活性高易于拓展：DevOps团队若要添加新的特性，通过新增微服务的方式而不需对别的组件造成影响，另外多个微服务也分担了整个系统的载荷，性能方面也会得到优化
- 提升团队工作效率：部门内多个小组负责开发和维护一个微服务集合，责任田划分清晰，分工明确
- 故障隔离：不同微服务相互独立，故障范围可控，即使是出现少量微服务故障导致停止服务，也不一定会导致整个系统不可用
缺点：
- 部署工作量大：随着微服务数量的增加，部署的工作量也会非常大，像我们安全运维团队从最开始的0个微服务，经过两年的开发，微服务数量拓展到了将近20个，还不包括技术中台提供的中间件的微服务
- 测试工作量高：测试需要覆盖的场景往往非常多，如果要对全场景和特性进行覆盖测试，工作量相当大
- 运营成本高：对于运维人员来说要监控多个微服务的性能、告警、CPU占用等信息，当
- 问题定位难度大：问题的产生往往会涉及到多个微服务之间的交互和通信，增加了问题定位的难度
本博客文章除特别声明外，均可自由转载与引用，转载请标注原文出处：http://www.yelbee.top/index.php/archives/221/
