个人认为微服务架构的核心问题还是在如何对软件进行适当的组件化，因此如何更合适地组织微服务的逻辑边界，或者说微服务的拆分原则是最应当关注的。总的来说，微服务拆分需要尽量从业务视角、服务自给自足、非强事务性、效率等方面考虑。这是设计层次的问题，直接关系到应用的灵...

本人认为，大部分的微服务都可以通过Service Mesh实现，也就是会替代目前的Spring Cloud，Dubbo的场景。不过也有些例外，比如ServiceMesh更社会所有的远程调用都是规范化标准化的，对于非标准的调用，ServiceMesh支持不是很好。其次对于性能要求很高的系统，ServiceMesh目前也不是很合...

微服务还没有准确的定义，与其说是一种架构，不如说是一种理念。微服务的核心诉求是应用或组件独立部署，减少没必要的耦合。如果设计的好，会使一些业务变更不影响其他业务，甚至可以做到灰度部署。但是，微服务到底微到什么程度，则是架构成败的关键。极端的，有将一个系统的每个接口均...

(一)安全访问控制 API 请求到达网关需要经过严格的身份认证、权限认证，才能到达后端服务。支持算法签名，支持 SSL 加密。（二）流量控制可控制单位时间内 API 允许被调用次数。可以根据 API 的重要程度来配置不同流控，从而保障重要业...

1、充分分析拆分的目的是什么，需要解决什么问题。2、是否具备微服务技术能力，是否已选型好相应的技术框架，技术变化对企业有什么影响。3、是否有完善的运维设施保障，比如快速配置、基础监控、快速部署等能力。...

引入消息队列的目的就是为了减少链路，减少依赖。举例说，用户注册后系统会给用户发积分，发优惠券，以及一些其他初始化操作。如果不用MQ的话，那么需要依赖积分服务，优惠券服务等其他服务。但是对于用户服务来说，只管注册不管其他的衍生服务，所以发送MQ后其他依赖方消费即可。...

微服务的缘起是因为代码冲突加剧 模块耦合严重项目质量下降团队效率下降由于微服务是无状态，支持横向扩充的，所以能提高系统的吞吐量。不仅仅是金融行业，其他行业使用微服务都需要关注数据一致性，安全性，幂等性这些问题。...

API网关能够将外部公共API与内部微服务API加以区分，使得各项微服务进行添加与边界变更。如此一来，微服务架构就能随时间推移而始终通过重组保护正确大小，且不会对外部绑定客户造成影响。另外，其还能够为全部微服务提供单一入口点，从而避免外部客户进行服务发现及版本控制信息...

我的一个小建议用kafka作为分布式消息队列，区分生产者和消费者

PaaS的基础技术无非就是docker和garden，这就如同java或者.net体系的选择一样，在容器之上需要构建容器集群，对于集群的管理非常复杂，一般都是编排引擎来做的事情，开源的有kerbenetes（简称K8S）或者docker swarm，k8s是google开源的，swarm是docker集成的，所以看你们选择了garden体系的...