架构师、准架构师们出来讲讲，如何从零搭建一个公司的应用架构

就你现在有什么，你到新公司就应该有什么

我不是一个准架构师，我只是一个程序员。不过，我可以提供一下我学习基础架构的知识从极客时间的几个专栏学习来的：
李运华《从 0 开始学架构》，杨波《微服务架构核心 20 讲》，杨波《微服务架构实战 160 讲》，胡忠想《从 0 开始学微服务》。
或许，你可以了解了解这些专栏的基础架构知识。

多看看架构设计的文章，看看别人怎么做的，自己依样画葫芦

没有思路就多看看别人如何搭建的

这玩意说清楚就是一本书...你在这简单问问不是白问么

@Luckyray 大道至简，真正落地的架构在架构师眼中不应该是复杂的，并且是可以传达给他人的，我是这么觉得的

我有这么一个设想，没有架构才是最好的架构，就好似在新浪云上搭建应用，无需考虑数据库、缓存，直接在代码中调用就好，如果还有网关，前后台能轻松集成和通信，岂不是最好的结果

不知道你说的架构是脚手架还是软件架构。。。从你的语言看，感觉更像是脚手架，脚手架的话，跟着各种工具的官方文档做就可以了。软件架构了话，看 领域驱动设计。

@daijinming 你这是在业务开发眼中看 infrastructure as sdk 出发点往往是美好的 XD

@lijingyu68 我说的是在没有确定领域的一个架子，不包括具体业务，但是基本的登录验证、菜单导航都有的

看 ABP 框架吧

软件架构：先根据手上的人力资源和计算资源的类型选择好技术栈吧，然后用现成的或者自己搞一个研发脚手架。
应用架构：无非选择巨石架构，微服务架构，ServiceMesh，更新一点的就是 Service less 了吧。也是根据目前手头上的计算资源和人力资源来选择。如果你的 IT 运维组能力较弱，例如只是虚拟机运维层面的，用巨石架构，扩展的时候用虚拟机复制。总的来说好像还是要根据手头上的人力资源来做决定。当然，良好的软件架构设计，可以方便你日后从巨石架构到微服务架构，或者到 ServiceMesh 的进化。
业务架构：这需要你十分了解你公司的业务了，多跟业务部门去沟通，业务架构没有标准答案的，都是随着业务发展而演变的。业务架构是为了业务部门服务的，方法论例如 DDD （领域驱动设计），这部分我没啥经验，就不多说了。

@index90 非常有条理化的分析，感谢。之前在小规模测试过微服务架构，感觉确实太繁琐，据网上说 ServiceMesh 也正是微服务架构后提出的思路，应该是对微服务的修正，这方面不知道有没有落地的方案，方便在三五技术开发力量的团队中执行起来

@daijinming 个人对 ServiceMesh 的理解，关键的组件是 sidecar，类似一个上网代理，挟持主机上所有的应用的网络请求，然后通过通过服务路由，发送到其他节点的 sidecar 上，最后由 sidecar 把请求发送到对应的应用上。可以想象一下，不管节点上有没有部署应用，每个节点上的 sidecar 都相互连接，组成一个服务网络。
ServiceMesh 的设计目的就是把服务路由，服务发现，流量控制等本来需要研发实现的东西，下沉作为基础设施来提供。研发应用的时候，就如使用 TCP/IP，DNS 等基础设施一样。
方案搜搜有很多，不过我没有落地的经验。以我目前的了解，现成的非侵入式方案有个比较大的问题，由于 sidecar 是一个代理，应用的请求数据包会经过两次 TCP 堆栈，会造成性能损耗和资源浪费。所以目前我都是在优化微服务研发框架上，把服务发现，服务路由等能力集成到研发框架里面（也就是侵入式）。Java 的如 Spring Cloud，Go 的如 go-micro

大处着眼 小处着手

想的有点多，等你遇到用户量增长就明白架构的意义所在了。现在空谈很难理解为什么要多做那么些工作

@index90 说的挺好
怼一下 等你的代码能先榨干网络的瓶颈再说

@daijinming 三五个开发力量就不要搞微服务这些了，得不偿失

对“架构”两字不知道怎么理解比较好~

一般我们都是从业务出发，先明确有哪些业务，每个业务需要那些单元，然后基于这些作分析最后明确一套技术方案跟应用框架~

不知道这算不算架构

@visonme 蒜滴

先把代码管理，搞定各种环境，版本发布流程。
小公司生产效率比起技术架构重要。
云产品的扩容性都很好， 最多引入消息队列平滑一些集中度高可异步的业务，基本是一个万能的起步架构。

这个问题太宽泛，日访问量十万的产品和日访问量十亿的产品所需要的架构师完全不是一个能力层级的。但总的来说，架构师肯定要熟悉各种解决方案，至少熟悉几种数据库，消息队列，缓存，微服务组件，搜索引擎，负载均衡，反向代理等等，需要的时候能挑选几种组合成解决方案。

具体情况具体分析，不看公司规模和业务来就是耍流氓。
首先要看公司目的是什么？
如果工作定性为外包公司，那就搭建脚手架、代码生成平台、测试发布和运维平台、定制常用的类库和吸纳开源类库，做到快速开发和代码复用。
如果是某个公司的技术部门，不以技术为主要盈利人数较少，那我觉得不要分布式和微服务，建议全部上云减少运维成本，用 nignx 做软负载均衡即可。
如果是技术型初创公司，建议是用手底下最常用的技术先快速实现业务，然后做的大一些时在用也就 java 体系、GO 体系来重写业务框架。
至于使用分布式体系，以 java 为例，我觉得一般公司可以考虑下面的步骤：
(1)所有服务采用统一的技术体系，推荐 Springboot
(2)搭建统一的脚手架，可以参考开源的一些，包括不限于分布式框架选型(Dubbo、SpringCloud)，分布式缓存选型(Redis)、日志处理和格式(采集建议 ELK)、消息中间件选型(Kafak、RokatMq)、分布式定时任务选型(ElasticJob)、统一的工具类库(cooms、guvua、fastjson 等)、Mybatis、代码生成器、Mybatis-plus、分页插件、统一异常定义和处理、统一的请求拦截器等。
(3)编码规范定义，可以参考阿里规范，但要考虑实用性，不可能每个人都强制遵守，那些是重要的，必须遵守，那些是可以适度放宽的。Maven、git 命名、打包、发布规范。
(4)建立自动化发布运维的框架比如 jenkins、ELK、钉钉邮件预警、网关(zuul 普罗米修斯)流量监控报警，以及 WIKI 和类似禅道之类的 BUG 管理平台
(5)这些算是通用的底子，然后要根据现有的业务进行拆分，比如微服务的话可以对业务拆分，比如用户平台、权限平台、商品平台、交易平台、风控平台等。微服务之上可以考虑增加业务聚合服务，直接对应部分前端。所有对外服务都应通过网关统一对外暴露，在网关层面考虑用普罗米修斯之类的对调用做监控。对于用户平台需要考虑统一的登录注册，可以考虑在网关层增加对调用的管理。交易平台可能跟风控相关，通过日志采集发往相关的处理系统再回写到相关表中，风控提供相关接口。比如商品可能需要检索系统，那可以考虑在基础之上增加 ElasticSearch 对商品信息进行检索。比如活动平台可以考虑增加规则引擎，高度自定义规则，将规则配置移交给运营人员，减少重复开发。根据公司业务拆分成不同的小平台和业务，再根据其特点选择技术。
(6)原则上有开源的系统，就学习并使用开源产品，这样减少开发时间，但随着业务发展开源产品不能满足时，可以根据自身特点开发自己的产品，比如业界的工作流可能不能满足公司的需求，公司可以自己开发一套基于 XX 上的改进版本。就类似与 Dubbo->Dubbox，甚至开源出来回馈社区

最后技术只是为业务服务的，任何公司都是依靠业务发展的，追求优秀的技术是正确，但要一定要考虑公司自身的情况和寻找合适的时间>_<

考虑资金，团队，业务循序渐进，留有余地。

@daijinming 当然是最好的结果，但是你忽略了中间的过程

三五个开发，先关注业务吧，活不下来也没法谈什么高大上的架构了。
选个 PaaS 平台，LBS，NameService，RDS 什么都有了，专心开发产品好了。

我觉得，不一定是高大上的技术才能凸显架构师的价值的，架构师还有一个很重要的工作，但很多时候被忽略的，就是如何合理地把现实的业务场景，转化为数据模型，以便能用有效的技术手段去实现。

@index90 对与 PAAS 我也是很赞成，我个人都是在新浪云搭建些小的应用，非常使用并且免运维，不用但是那天服务器趴了。可以公司的客户很多是内网部署，人家给你几台服务器（虚拟的），自己需要维护这些服务器。这种情况下可以部署 PAAS 吗

谷歌的微服务架构
https://github.com/GoogleCloudPlatform/microservices-demo/

相关文章 https://mp.weixin.qq.com/s/sDMX7ICSasyzrFQVeK4vmw

主要看干活的人有多少……

rails new my_app


好了

@whp1473 大神厉害。