微服务是现在互联网的一个热点，谈到微服务，可能要说两个人，这两个人对微服务的架构定义有深远的影响，一个是马丁福勒(Martin Fowler)，另外一个是Netflix的架构总监。
微服务概念
马丁福勒在14年的时候在他的博客上写了一篇很长的博文来介绍微服务架构，里面提到了微服务的核心特点要有
微服务架构只是一种架构风格，每种架构都有自己的架构特点。
早先单块架构，所有的应用在一个应用中，微服务把这些一个个的应用拆出来。
微服务是运行在独立的进程中的，现在的容器本质上也是一个进程，以进程的方式横向扩展微服务
原先服务间通信的时候，可能有重量级的通信方式如soup协议，但是微服务主张轻量级的协议比如说HTTP，减少消息格式。
基于业务能力构建，比如说商品服务，订单服务，这些业务能力去构建微服务
每个团队可独立的部署微服务，这样迭代就会比较快
早先是由独立的架构团队来统一技术站，统一存储方式，微服务就不一样，主张每个团队根据自己的技术选择技术栈。
松耦合，面向服务架构，有界上下文
在分布式系统中，当每个团队有独立的数据源的时候，又会带来什么样的挑战呢？
微服务权衡
微服务虽然是现在的一个热点，但是作为架构师来说，我们要非常清晰的了解它的优势和挑战。因为架构最重要的一个职责就是权衡，那么微服务有哪些利和弊呢
优势：
强模块化边界，模块化是一个很重要的方面，最开始用类做，后面用组件，类库的方式，微服务则是用服务的方式做模块化。不用像jar包一样做分享，而是通过调用的方式
可独立部署，每个团队根据自己的需要去开发，部署。单块应用可能需要很多团队一起有一些协同开销
技术多样性，每个团队可以根据自己的需要，业务的实际情况，选择最优的技术栈，有的团队擅长Java，有的擅长NodeJs，当然技术栈不要太多就是了
劣势：
分布式的复杂性，服务太多，一般的开发人员，团队都没法理解系统到底是怎么样工作的
最终一致性，每个团队都有自己的数据拷贝，有可能出现数据不一致的问题
运维复杂性，需要很多的服务，这个时候系统的可靠性，稳定性都有挑战的
测试复杂性，现在再去测试的话，功能在各个团队的，需要做联调，测试的复杂性就很高
微服务有利也有弊，微服务带来的复杂性，对运维的挑战是很大的，那么要如何应对这些挑战呢？
微服务引入
企业应该在什么时候引入微服务，这个是有讲究的。
单体应用，复杂性不高的时候，单体的效率会比较高，但是当项目复杂度不断的升高的时候，单体的效率则越来越低
微服务如果最开始就用微服务的话，生产力反而会比较低
单体与微服务曲线的交叉点的时候，就是引入微服务的时候。这个点需要架构师去综合的考虑，一般在团队到达100人的时候，就很需要引入微服务了。
有的人在一开始设计的时候就倾向于走向微服务，这个其实并不推荐，很难去把控拆分服务的边界。而且风险会比较高，很多时候我们单块优先，先用单块应用，随着业务不断的推进，规模不断扩展，这个时候再去进行微服务化。根据需要一个个的把相关模块拆出来。
有些架构师的观点觉得架构是设计出来的，有的架构师觉得架构是演进出来的。这个自行思考吧
是否适合微服务
康威法则：设计系统的架构受制于产生这些设计的组织的沟通结构。
那么什么样的组织架构更适合微服务呢？传统企业里面一般开发的流程流动方式为：都是按照明确的职能进行划分的
产品团队
用户体验
研发团队
测试团队
...
DBA团队
运维团队
这样的团队划分需要多次的协调，每一个团队都要进行沟通协调，成本比较高，反馈也比较慢。在微服务下则需要一些跨职能的团队，每个团队内部都有专家，用户，研发，测试等等，这些人围绕在微服务周围进行处理。
一个团队的规模大致12个人左右，亚马逊的CTO曾经说过：
谁构建，谁运行，谁负责
这样则要求微服务的团队内部能形成闭环，这个时候就能更好更快的响应业务的需求。微服务架构本质上是一种组织架构的重组。
最后
这里我们从微服务的概念开始引入，然后讨论了微服务的优缺点，以及企业在何时去引入微服务才是合适的，最后说了下微服务团队的特点。
后续我们再讲微服务的具体实施，项目的架构细节
参考
注：
本文独家发布自金蝶云社区
