微服务架构综述——微服务的本质
微服务的诞⽣是在互联⽹⾼速发展，技术⽇新⽉异变化以及传统架构⽆法适应快速变化等多种因素共同推动下的必然产物。
随着越来越多的传统⾏业开始依赖互联⽹技术打造其核⼼竞争优势。如何从系统架构的⾓度出发，构建灵活、易扩展的系统，快速应对需求的变化；同时，随着⽤户量的增加，如何保证系统的可伸缩性、⾼可⽤性，成为系统架构⾯临的挑战。
微服务的本质特征体现在如下⼏个⽅⾯（从整体架构的⾓度）：
1. 服务作为插件：传统实现组件的⽅式是隔离独⽴的部分或抽取公⽤的部分，构建共享库，从⽽达到解耦和复⽤的效果。共享库的变化意味着整个应⽤要被更新，并且需要被重新部署。如果应⽤由多个共享库组件组成，那么任何库的变更都将导致应⽤重新发布。⽽微服务架构的⼀个显著优势是，能以松散的服务⽅式，构建可独⽴化部署的模块化应⽤。当然，分布式调⽤会使效率降低，⽽且可靠性和稳定性也严重依赖于⽹络状况。
2. 围绕业务组织团队：提倡以业务为核⼼，按业务能⼒来组织团队，团队中的成员具有多样性的技能。
3. 关注产品⽽⾮项⽬：提倡产品模式构建，让团队负责整个服务的⽣命周期。这种模式可以较好避免项
⽬模式中出现的，团队成员缺乏主⼈翁精神、难以制定有效的奖惩机制、团队成员缺乏产品成就感等问题。
4. 技术多样性：提倡针对不同的业务特征选择合适的技术⽅案，有针对性地解决具体的业务问题。对应单块架构系统，初始的技术选型严重限制其将来能否采⽤不同语⾔或框架的能⼒。微服务架构，使我们更容易在系统上尝试新的技术或解决⽅案。即使对⼀项新技术的尝试失败，也可以抛弃这个⽅案，并不会对整个产品带来风险。
5. 业务数据独⽴：传统的数据库⼤多是关系型数据库，存储的数据都是以结构化信息为主，但随着互联⽹的快速发展，数据的结构并不具有确定性，或者说结构发⽣变化的频率⾮常快，如何有效维护业务数据将成为迫待解决的问题。微服务架构提倡服务⾃主管理相关业务数据，有以下⼏个显著优势。
①能够随着业务的发展，提供业务数据接⼝集成，⽽不是以数据库的⽅式和其它服务集成。
②能够随着业务的发展，选择更合适的⼯具管理或者迁移业务数据。
6. 基础设施⾃动化：微服务架构将应⽤程序本⾝分成多个⼩的服务，每个服务都是⼀个独⽴的部署单元。传统只需要部署⼀次就能上线的单块架构应⽤，采⽤微服务架构后，将需要对每个部分分别进⾏部署。这也意味着部署与运维的成本会随着服务的增多呈指数级增长。因此，微服务的实践将促使企
业或者团队不断寻更⾼效的⽅式完成基础设施的⾃动化以及DevOps（⼀组过程、⽅法与系统的统称，⽤于促进开发、技术运营和质量保障部门之间的沟通、协作与整合）运维能⼒的提升。
7. 演进式架构：单⼀的技术平台已经⽆法适应市场的快速变化，组织应该随着业务的发展，随着企业的发展，不断尝试并改进架构设计，真正做到业务驱动架构，架构服务于业务。
分布式和微服务的关系
相较于SOA的思想（对于复杂企业IT系统，应按照不同的、可重⽤的粒度划分，将功能相关的⼀组功能提供者组织在⼀起为消费者服务），两者间的区别如下：
微服务架构实现
SOA实现                                                    微服务架构实现
SOA实现
企业级，⾃顶向下开展实施                        团队级，⾃底向上开展实施
服务由多个⼦系统组成，粒度⼤                ⼀个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构            ⽆集中式总线，松散的服务架构
集成⽅式复杂（ESB/WS/SOAP）            集成⽅式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂        服务能独⽴部署
虽说微服务有诸多优点，但在实施过程中需要对以下因素进⾏考量：
1. 分布式系统的复杂度
2. 运维成本
3. 部署⾃动化
4. DevOps与组织架构
5. 服务间依赖测试
6. 服务间依赖管理
服务组件的响应性能，服务间协作的可靠性，异步通信机制对调试带来的困难，数据⼀致性问题等，都将出现在微服务架构的实施过程中。因此，在实施微服务前，我们需要清楚地了解它将带来的风险，从⽽使团队能到更合适的⽅式来有效实施微服务。

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