《人月神话》中提到，软件世界没有“银弹”，这句话当然适用于架构领域
从网络、性能、运维成本、组织架构与集成测试五个方面分别进行阐述。
第一点，跨进程通信带来的新问题。
单体应用是在单机中进行进程内通信，通信稳定性相当好。但是打散为分布式系统后，变为进程间通信，往往这个过程还伴随着跨设备的网络访问
第二点，较高的响应延迟。
相比传统单体架构进程内通信，跨进程、跨网络的微服务通信在网络传输与消息序列化带来的延迟是不可被忽略的
第三点，运维成本会直线上升
每一个服务都是可独立运行、独立部署、独立维护的业务单元，再加上互联网时代用户需求的不断变化以及市场的不稳定因素，运维人员每天面对成百上千台服务器发布几十次已是家常便饭，传统手动部署显然已经无法满足互联网的快速变化。
第四点，组织架构层面的调整。
微服务不但是一种架构风格，同样也是一种软件组织模型，以往软件公司会以职能划分研发、测试、运维部门进行独立管理考核，而在微服务的实施过程中，是以业务模块进行团队划分，每一个团队是内聚的，要求可以独立完成从调研到发版的全流程，尽量减少对外界的依赖。如何将传统的职能团队调整为按业务划分的研发团队，同样是对管理者的巨大挑战，要知道人的思想比架构更难改变。
第五点，服务间的集成测试变得举步维艰
系统被拆解为很多独立运行的单元，服务间采用接口进行网络通信。要获取准确的测试结果，必须搭建完整的微服务环境，光这一项就需要花费大量的人力物力。同时，因为微服务是跨网络通信，网络延迟、超时、带宽、数据量等因素都将影响最终结果，测试结果易产生偏差。
微服务最佳实践
第一点，微服务的划分原则。
通常会从业务场景、团队能力、组织架构等多种因素综合考虑，这特别考验架构师的业务能力。
单一职责原则。
每一个微服务只做好一件事，体现出“高内聚、低耦合”，尽量减少对外界环境的依赖。
服务依赖原则。
避免服务间的循环引用，在设计时就要对服务进行分级，区分核心服务与非核心服务。
Two Pizza Team原则。
就是说让团队保持在两个比萨能让队员吃饱的小规模的概念。团队要小到让每个成员都能做出显著的贡献，并且相互依赖，有共同目标，以及统一的成功标准。一个微服务团队应涵盖从设计到发布运维的完整生命周期，使团队内部便可以解决大部分任务，从人数上4~6人是比较理想的规模。
第二点，为每一个微服务模块明确使命。
模板
XX 微服务用来
在出现痛点场景的情况下
解决现有的 XX 问题
从而达到了 XXX 的效果
体现了微服务的价值
示例
商品检索微服务用来
在商品数据全量多维度组合查询的情况下
解决了 MySQL 数据库全表扫描查询慢的问题
从而让查询响应降低到 50ms 以下
有效提升了用户体验
第三点，微服务确保独立的数据存储。
微服务架构下，因为数据库绝不允许其他团队访问，关联查询只能变为 API 调用形式，程序实现层面比单库复杂不少。
第四点，服务间通信优先采用聚合器模式。在微服务间通信时存在两种消息传递模式：链式模式与聚合器模式。
采用聚合器模式后，业务流程与编排集中在“订单流程服务”中，可对整体业务进行有效编排，支付与扣库存可以并行调用，可以有效提高系统的性能。
第五点，不要强行“微服务”化。
架构是解决当前需求和痛点而演进的。在满足需要的前提下，选择合适的而不是选择最好的，合理降低成本才是好架构师该考虑的事情。
微服务架构的适用场景
新规划的大型业务系统
敏捷的小团队系统
历史的大型留存业务系统
标签：服务,运维,挑战,业务,间通信,架构,团队 From： https://www.cnblogs.com/jiaozg/p/17219102.html