我在M2公司做架构之部署

一、单体应用

1.部署

关于单体部署可参考我写的如下文章，这里不再赘述:
jar包部署指定不同环境
单体应用自动化部署
springboot jar包部署如何不占用过多的服务器内存
SpringBoot之热部署
多模块应用自动化部署

2.集群部署

所谓集群部署就更简单了，在两台服务器搭建相关的环境，并部署一样的单体应用微服务，然后通过nginx或apache进行相应的负载均衡+代理配置即可。
具体如何配置可参考如下我写的文章:
nginx反向代理和tomcat集群(适用于ubutnu16.04及其centos7)

3.遇到了哪些问题

从单体应用部署的角度来看，通常存在如下问题:

• 部署频率不能过高，受制于项目的庞大，庞大的项目初始化启动将非常缓慢，部署时间很长；
• 资源无法隔离(某个接口请求量大很容易造成整个服务陷入”假死”状态)。

要解决这样的问题，有如下方法论可供参考:

• 第一种:优化相关代码，能够整体提高项目的质量以及性能；
• 第二种:结合实际情况，逐步进行服务拆分，慢慢的减少项目的庞大；
• 第三种:通过集群的方式来达到一种高可用的状态。

三种方式，从成本的角度来看(由低到高):
第一种>第二种>第三种。

优化代码是成本最低的，但如何优化很重要，优化的前提必须要明确是否是代码的问题，不然就没意义，这需要团队里有对性能方面的专家或者是经验丰富的小伙伴，从代码层面入手，相当于是从底层，成本相对较低。

其次，服务拆分的成本相对较高，一方面可能涉及到部署架构方面的调整；另外一方面一个系统从0到1，再从1到2这样的情况，人员的不断更新迭代，历史代码+历史业务相关是最大的难点，需要业务知识非常熟练的小伙伴与有相应微服务拆分实际经验的小伙伴一起配合才有可能将这件事情做好，当然了，最重要的是需要上面领导的同意与支持，不然的话，很难进行下去。

最后，集群是最省事的，但成本是较高的，因为很多性能方面的问题并不是通过加机器就能解决的，相反机器越来越多，服务管理的复杂性也会随之增高，问题定位的时间成本也会增高，同样因为集群，部署架构需要做出更大的调整，必须要推行并实际落地自动化运维体系，否则真的会让相关人员”累死”。

4.这些问题我是如何解决的

结合公司具体业务进行分析，并结合当下项目的进展情况而定，如果是短时间需要交付给客户的话，这个问题又很难短时间解决，暂时可以以大局为重，保障项目总体进展顺利，暂时忽略一些小问题，留待下个版本迭代解决。如果有一段充足的时间的话，从代码层面解决这个问题，绝不让其扩大化。当初在创业公司做编程教育项目的时候，基本上就奉行的是这种方式。
代码层面的优化有很多，例如:
具体业务代码执行的顺序、具体业务代码相关API调用、具体代码极度的消耗CPU或内存资源、JVM相关的调优等等。我写过的这篇文章曾提到过部分内容可供读者朋友参考:老J的技术分享之总结

二、分布式应用

1.部署

有句话叫做，集群不一定包含分布式，分布式一定包含集群。
部署方面，分布式要复杂很多。一个分布式应用通常有如下:

• 20个或以上的微服务；
• 服务注册中心；
• Redis；
• 消息队列(Kafka、RabbitMQ等)；
• 分布式文件系统；
• 数据库(MySQL/Oracle)；
• Elastic Search；
• MongoDB；
• 分布式事务中间件(Seata、Tx-LCN、MyCat等)；
• 分布式定时任务(Elastic-Job、Xxl-Job、Quartz等)；
• 网关；
• 限流中间件(Openrestry+Lua、Sentinel等)。

2.会遇到哪些问题

• 数据库中的数据一致性问题；
• 各个微服务稳定性问题；
• 第三方中间件管理问题；
• 第三方中间件性能问题；
• 微服务的总体管理问题；
• 各个微服务之间的通信问题；
• 部署流程问题；
• 各个微服务及其第三方中间件监控问题。

3.这些问题如下解决呢

我个人总结了如下方法论，仅供参考:

• 团队拆分，不同的团队管理不同的微服务，按照公司业务进行拆分，粒度的粗细需结合实际情况而定，但一定要有一个人总体协调和管理；
• 专业的运维团队，落地自动化运维体系(监控自动化、部署自动化、服务和第三方中间件运用自动化工具进行管理等)；
• 团队定期Review代码以及复盘过往的问题或针对未来可能的问题进行头脑风暴；
• 推行并落地符合当下公司技术团队管理的制度，从制度层面进行约束；
• 选择恰当的时间，技术团队中的成员进行相关的技术分享；
• 专门的问题管理系统和运营负责沟通、记录、反馈来自客户的问题(可以是业务，也可以是某个具体的功能)。