微服务架构（转）

1.微服务的定义？微服务需要“微”到什么程度？

（1）每一个微服务是一个独立的自治系统，不依赖外部组件，能够独立运行； （2）对外只能通过API提供服务或者获取服务； （3）粒度足够小。
微服务的粒度与团队组织方式是相关，与业务功能的构成相关，与数据相关。
在业务功能方面，尽量做到一个模块中的业务高度类聚集，和外部模块做到松耦合，获取灵活性；在数据方面，一个微服务尽量不要和外部频繁的交互数据，大量的API交互对性能和可靠性都有影响。

2.微服务的重大优势是什么？它是未来吗？

微服务，是一种去中心化的架构。一般和更细粒度的容器配合使用，天生自带很强的共生性。
从早期的集中式架构，到分布式架构，再到现在更细粒度化的微服务，其实一直朝着去中心化的趋势发展，具备更强的灵活性以及更适合云的特点。
微服务是未来一种非常主要的、应用广泛的架构，但并不一定说它会统治一切。微服务化更适合无状态、高迭代的业务场景。

3.微服务在实践过程中最大的难点是什么？

微服务在实践过程中，最大的问题是团队之间的运作和管理。康威定律提到，有什么样的团队组织方式，就有什么样的业务架构。业务架构，是和团队组织架构相匹配的，当我们把一个大的系统，拆分成小的服务时，团队会随之变化。团队成员需要适应微服务的开发模式，微服务对每个程序员有着更高的要求。
微服务实践的难点不在于没法拆分，难点在于很多人的思想停留在以前的架构思想下。建议逐步改造、持续迭代地改造架构。新业务、新团队可以独立地采用微服务化运作。

4.微服务、容器技术两者的关系？两者结合带来什么新趋势？

微服务是一种架构思想，而容器，或者说以Docker为代表的容器技术，是一种运行载体。容器天生适合细粒度的微服务，容器管理和分发需要Docker的支持。两者结合，就是去中心化思想的实践。
伴随互联网与云计算的发展，什么样的架构或者产品研发模式是适合云模式的？是传统的集中式架构吗？分布式架构吗？现在创业型公司的特点：完全基于云端，轻资产，小团队作战，快速的产品迭代。为了适应这些特点，必须基于云的原生特点去设计应用架构，所以微服务和容器发展的新趋势，就是去实践Cloud
Native。

5.怎么处理微服务与外部相连，以及获取数据？

微服务是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以。
换句话说，微服务和微服务之间的数据通讯是通过API调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。

6.微服务与容器结合会发展出新趋势–Cloud Native，什么是Cloud Native？

在云时代，全部应用都基于云去构建，并不适合套用传统的研发模式。Cloud
Native是指云原生的应用架构，是专门针对云的架构。它主要包括三个部分，一种全新的架构思想（微服务），一种业务运行管理模式，以及一种团队组织管理方式。关乎DevOps、小团队、敏捷开发。Cloud
Native既不是一个新的技术，也不是一套新的架构，而是产品研发、运营的全新模式。它是在云的生态场景生长出来的，和云的关系是一种鱼和水的关系。

转自【话题讨论】理解微服务架构，实践云原生应用！