微服务不是银弹
Fred Brooks 在他的两本著作《没有银弹：软件工程的本质性与附属性工作》和《人月神话：软件项目管理之道》里都反复强调着一个观点：“软件研发中任何一项技术、方法、架构都不可能是银弹”。
目的：为什么选择微服务
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
外部因素
- 没有什么技术能包打天下。考虑到技术异构选择微服务是没有选择、无可避免的。
- 人才储备。选择微服务能使高水平开发、运维人员来实现关键业务服务，外围功能交给非核心人员，以便保证系统整体的稳定和局部的容错、自愈与快速迭代。
- 甲方要求。甲方招投标文件技术规范明文要求。
- …
内部因素
- 快速变化业务的自主选择。微服务让系统有更好的可观测性、快速迭代和自愈能力。
- 大规模的、业务复杂的、历史包袱沉重的单体系统会自然向微服务演进。
- …
前提：微服务的条件
康威定律
决策者与执行者都能意识到康威定律在软件设计中的关键作用。康威定律的核心观点是“沟通决定设计”，其社会学和管理学的规律决定了假如产品和组织能够经受住市场竞争，长期发展的话，最终都会自发地调整成组织与产品互相匹配的状态。
为了推进软件架构的微服务化而配合地调整组织架构，通常不是一件容易的事情。因为所有的技术上的决策实际都是政治上的决策。解决这个问题不仅需要执行者有良好的社交能力，还需要更上层的决策者充分理解架构演变同步调整组织结构的必要性，为微服务化打破局部的利益藩篱。
技术专家
开发业务的普通程序员可以不去深究跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展这些系统性的问题，它们被隐藏于软件架构的最底层，被掩埋在基础设施之下。靠谱的软件架构应该要由深刻理解微服务的技术专家来设计建造，健壮的基础设施也离不开有经验的运维专家的持续运维。
如果整个团队中缺乏能够在微服务架构中撑起系统主干的技术和运维专家，强行进行微服务化并不会有任何好处，至少收益不足以抵消复杂性增加而导致的成本。
一个残忍的真相是：软件架构的趋势将导致开发者的分层，从如今所有开发者都普遍被认为是“高智商人群”的状态，转变为大部分工业化软件生产工人加上小部分软件设计专家的金字塔结构。
自治和监控
由于微服务数量多、发布快，迅速升级和回滚的自动化是必要的，但监控对于任何一个系统都需要。
微服务自动化的最终目的是构筑一个可持续的生态系统，现阶段仍然是一个过于理想化的目标。建设微服务的不同时期，由不同程度的人力去参与运维完全可行的，只要满足与系统规模和目标相匹配的自动化能力。只有朝着这个目标去发展自动化与监控度量，避免自动化与度量监控反过来成为人与系统的负担。
复杂性
架构是演进式设计的，对于小型系统，单体架构就是最好的架构。复杂度的提升自然而然过渡到微服务架构中。
边界：微服务的粒度
下界
微服务粒度的下界是它至少应满足独立，内聚，完备三个特征。
独立：独立发布、独立部署、独立运行与独立测试。
内聚：强相关的功能与数据在同一个服务中处理。
完备：个服务包含至少一项业务实体与对应的完整操作。
上界
微服务粒度的上界是一个 2 Pizza Team，能够在一个研发周期内完成的全部需求范围。
这是由于邓巴数的存在。