- 创业互联网公司如何搭建自己的技术架构？
- 学生党该如何合理利用阿里云的云服务器？
- 网站外包完成后，服务器是阿里云的，是不是修改下阿里云密码，外包就不能修改网站代码？
- 为了减少接口的响应时间，有哪些优化措施？（可以从架构、代码等各个角度谈）？
创业互联网公司如何搭建自己的技术架构？
对于一个刚刚开始创业的互联网公司来说，其实谈什么架构、谈什么并发数量都意义不是特别的大，其实越是强大的架构，越是投入大，花钱厉害。
对于刚刚开始创业的互联网公司来说，技术并不会成为你起步时的瓶颈，因为你并没有那么多的用户，不会出现那么高的并发量，就算偶尔有非常高的并发出现，我们也可以通过硬件上的一些小投入来解决，不需要在架构上面思考太多。
如何设计产品？如何投入市场？市场的体量如何？需要帮助用户解决什么痛点？如何获利？
这些问题才是一个创业公司应该考虑的问题。
我们要清晰的明白一件事情，技术是为运营服务的，只有将产品运营好了，公司赚钱了，或者是未来能够赚钱了，这样，我们才能够再来谈架构。
因此，对于刚刚开始创业的互联网公司，活下去是最重要的，活下去才能够发展，那为了活下去，应该选择什么样的架构呢？
SOA？No，投入太大，我需要有人来做服务的设计，有人做前端，如果服务较多，还需要做服务的治理。
***用阿里云的方案， 最简洁的方案是一台服务器搞定所有，但不建议这么干，以后要扩展根本跟不上， 基础就是三大件分离:
数据库服务器(RDS，每个月几十块钱)
文件服务器(OSS， 一年一百都不到)
学生党该如何合理利用阿里云的云服务器？
就算是在阿里云ECS上搭建一个博客，你也可以做的更多，特别是你出于学习目的，最主要的是在阿里云上让你快速体验各种架构变得非常容易。也就是说你不光是从开发者使用ECS的角度去学习阿里云ECS。你要去考虑如何让你的应用部署变得弹性可扩展、高可用、安全、应用如何和阿里云上的其它服务集成。1，你可以实现最简单的All-IN-ONE的架构，把你的博客应用（也可以是你觉得有价值的其它WEB应用、Java应用等），数据库，内容都部署在一个ECS实例上。2，可以通过阿里云负载均衡SLB+ECS+RDS+OSS实现企业级应用部署，这样你可以学会从企业用户的角度去考虑如何在阿里云做一个弹性部署架构，如果在应用层做扩展，如何实现两层架构，如何将结构化数据和非结构化数据分别处理。3，可以通过云盾+ECS，学习云上的安全知识。通过云监控，学习如何管理阿里云服务器ECS。4，可以通过SLS简单日志服务，学习如何分析你的应用程序（比如博客）产生的日志，进而了解访客的各种行为。作为一个初学者，我先向你推荐这几个场景，希望你能从架构的角度去学习阿里云上的ECS服务器。
网站外包完成后，服务器是阿里云的，是不是修改下阿里云密码，外包就不能修改网站代码？
谢谢邀请
租借服务器是阿里云的，一般是存在两个账号，控制台的账号，还有一个就是你在阿里云服务器上的操作系统的登陆账号。
所以要想完全不然让外包修改你的代码，原则上这两个账号的密码都要修改，并且在登陆上增加一个手机验证的功能，就可以了。
希望能帮到你
事情没有你想得那么简单，网站存着后门呢？
在线修改代码很简单的。
比方说，你登陆后台是需要账号密码的，但是也可以通过特殊手段不用账号密码或其他方法进入后台。
还有你说修改阿里云密码只是改了个阿里云密码，服务器的密码呢？数据库密码？
不过这样说吧，既然选择外包了，就要选择相信对方。双方建立在共同信任的基础上来合作。
还可以修改:
网站后台系统登录密码
网站数据库密码(但改了[_a***_]密码，要相应修改网站程序配置文件否则网站就打不开了)
FTP密码(如果配置)
修改密码最主要作用是:
密码集中由自己管理
或密码泄露引起意外。
但是，若外包方要恶意修改破坏，那你防不住啊。外包方作为你网站建设者，也是后续网站运行的义务或潜在保障者，一般来说他们不可能监守自盗。
1.首先既然选择了外包公司，应该你们建立了信任，如果不信任肯定也不会合作
2.其次外包团队一般接的单，比较多，项目经理应该是有职业操守的，他们连这点都做不到，以后就别在圈里混了。
3. 为了以防万一项目移交后，还是把网站后台密码、数据库账号密码、运维平台密码，阿里云服务器密码统统改一遍，尽量密码改复杂点，防止暴力破解；
以上几点如果你做到了，一般都问题不大，除非黑客高手黑你，或者外包团队之前故意留后门（就跟美国***一样，咱们的电脑硬件在出厂的时候就自己植入木马了，防不胜防啊）之前科研机构怕优盘不安全，打算刻光盘，谁曾想到刻录软件是美国人开发的，你刻录过程中已经被植入木马了 哎，不说了 扯远了。
你对后门一无所知。我们这些人也不可能告诉你，一定怎样，不一定怎样。重点是找存活年头长的公司，结清尾款别拖欠，以及保留材料准备***。
什么？准备***？是的，如果你网站出事了，先考虑外包公司。可能准备了半天用不上，总比用上了好。
为了减少接口的响应时间，有哪些优化措施？（可以从架构、代码等各个角度谈）？
1、代码中注意缓存、连接池、对象池的使用，不要在循环中读、写库；
2、数据库读写分离；
3、***文件压缩、动静分离(直接nginx访问、不走应用服务器)；
6、 各服务服务器(nginx/tomcat/mysql/redis/mq)集群、水平扩展；
7、配置优化:如OS、Nginx、中间件、数据库、JVM等；
8、CDN支持、域名加速以上是可选方式。离开场景谈性能优化都是耍流氓，实操过程中引入测试团队进行压力测试、验证调优，同时要引入性能监控工具、便于后期不断定位、调优。
1. 服务器做成弹性伸缩的集群或ServerLess版。
2. 尽量少用成熟的MVC框架，因为它太大了，吃***。尽量用原生代码写一个小的API框架。
3. 不经常变更的数据存储到Redis中，异步操作写入消息队列中。
4. 上传文件使用OSS直传。
响应时间，主要是从服务器处理数据的时间加上网络传输的时间，对于服务器处理时间，你可升级服务器、***用缓存或者改进算法；在传输方面你可升级带宽或者***用压缩传输，也可以参考诸如protocolbyte这些协议
我们在开发过程中，当然是希望自己项目接口的响应时间越短越好，至少我看着自己开发出来的代码，都是毫秒级的响应，会有一种自豪感；那么我们项目做了哪些优化，和大家分享分享。
先从小处着手，代码写的好坏，直接影响到接口的响应速度；当然这里也不可能展开详谈每一行代码怎么写，主要还是说一下措施：
代码规范：我经常会以自己的标准去衡量其他开发人员代码的好坏，虽然我也不是什么大牛，但毕竟做了十多年的开发，所以很多时候组内年轻人的代码，在我眼里都是不合格的，为了短时间内提升他们的代码水平，只能制定详细的代码规范让他们去遵守；
项目级的处理方案：有些公共的功能，并不需要每个开发去写代码，比如异常处理，直接往上抛，会有统一的代码捕捉异常进行处理的。
集体Code Review还是有必要做的，一方面起到一个威慑的作用（大部分人都好面子，如果自己写的代码太烂被大家看到，也会不好意思，所以写代码的时候会小心一些），另外确实可以让开发人员取长补短。
缓存很重要，所以单独拿出来说。
出参入参直接缓存：某些场景下，是可以直接把入参作为key，出参作为value，直接缓存起来的，比如放到Redis中；我们有个项目是做费率计算的，需要根据入参查询费率表，并有大量的计算操作，这种场景有两个特点：一是费率信息不会改变，二是计算复杂费时，这个场景就非常适用于出参入参直接缓存（出参=计算结果）。
1.利用缓存，构建一级缓存和二级缓存
2.数据库读写分离，更新使用乐观锁
3.返回结果固定不变的，可以把结果缓存到cdn
4.利用openresty做接口网关
5.接口服务组建对等集群，进行负载均衡
6.拆分服务，用mq对业务解耦，同时可以***用异步编程模型或者事件驱动模型
7.对接口进行压测，找出瓶颈进行调优
